2017-05-15

<clever> johnramsden: most vm stuff will create a tun/tap device linked to the guest, and then add that device to the bridge
<clever> johnramsden: yeah, that looks good
<clever> nix-build -E 'with import <nixpkgs>{}; callPackage ./default.nix'
<clever> 2017-05-14 21:13:41 < clever> rcschm: you need to run nix-build directly on that file, and not reference it from a config.nix or put it in a special location
<clever> and now you have infinite recursion
<clever> and i highly suspect that config.nix says that arangodb is in https://pastebin.com/AiNJdFus
<clever> the reason i'm asking, is because line 3 of https://pastebin.com/AiNJdFus asks nixpkgs for arangodb
<clever> is there anything about arangodb in it?
<clever> what is in that file?
<clever> rcschm: do you have a ~/.nixpkgs/config.nix file?
<clever> -A doesnt work like that
<clever> rcschm: what is in config.nix?
<clever> johnramsden: meant to say //
<clever> rcschm: you need to run nix-build directly on that file, and not reference it from a config.nix or put it in a special location
<clever> johnramsden: lib.recursiveUpdate takes 2 attrsets and does similiar to {}
<clever> johnramsden: there is another function that does a deep merge
<clever> johnramsden: and // overwrites the entire defaultGateway attribute, clearing address
<clever> johnramsden: and line 25-32 contains a defaultGateway = { interface = "br0"; };
<clever> johnramsden: the line 18-25 derivation contains a defaultGateway = { address = "..."; }; attribute
<clever> johnramsden: line 26 is the problem
<clever> and where did you put that file?
<clever> can you gist the nix file your editing?
<clever> rcschm: if you just want it to work by itself, you do this: https://gist.github.com/cleverca22/50ebae917d8d9a60a07d792d7829bc9f#file-default-nix-L1
<clever> johnramsden: networking = { } // (lib.optionalAttrs useBridge {});

2017-05-14

<clever> johnramsden: try wrapping it with ( and ) to enforce the order of operations
<clever> rcschm: nix-env will make a mess of your profile and waste a lot more disk space in the long run
<clever> rcschm: and also, you want to use nix-build for testing, not nix-env
<clever> rcschm: what is the exact command you are running, and what directory is it being ran in?
<clever> and i think false turns into an empty string, its weird
<clever> i think true casts to 1 when that happens
<clever> Fare: the attributes inside a derivation get cast down to a string, and dontStrip is then checked by a bash script for truthiness
<clever> johnramsden: in the snmpd.nix example i linked, the passwords value is available everywhere after line 3
<clever> Fare: yeah
<clever> rcschm: yeah, line 21/22
<clever> rcschm: we need to first look at the original derivation, and know what its doing
<clever> the {....} attrset is the main value in the file, and it has been prefixed by a let block
<clever> johnramsden: any place you can put a value, you can also do this: let <key=value pairs>; in <value>
<clever> rcschm: i think the patch list on the original arangodb derivation is having the problem
<clever> can you gist the full output of nix-build?
<clever> something needs to start a build of v8
<clever> the build directory is missing
<clever> ah, its not a git submodule
<clever> the hash will need to be updated as well
<clever> and it will get all of the submodules for you
<clever> set fetchSubmodules=true; inside the fetchFromGitHub call
<clever> using fetchFromGitHub?
<clever> which fetch function are you using?
<clever> is it on github and using git submodules?
<clever> just pop in the right url and point nix-build at it
<clever> if you just put cmake in the buildInputs and unset builder=, then cmake will just magicaly do everything for you
<clever> you almost never want to use builder= in a derivation
<clever> can you gist the nix expression?
<clever> what happens when you run nix-build on that expression?
<clever> th cmake setup hook will deal with running cmake for you
<clever> rcschm: start by setting src, name, and buildInputs = [ cmake ];
<clever> i had to make $out and chown them to the right user, before a non-root make install, to even reproduce the problem
<clever> and you cant just sudo nix-shell, because it now has write to its buildInputs and doesnt fail
<clever> you cant just "make install" in a nix-shell, because it lacks write to $out
<clever> for example, one of the qt modules on darwin, tries to write to one of its input directories, which are read-only
<clever> MichaelRaskin: though i have seen some rather hard to debug problems in the installPhase
<clever> they tried to make their own pure build system
<clever> and it lost NIX_CFLAGS_COMPILE
<clever> MichaelRaskin: only time ive seen it fail spectacularly, is when a python build system steralized the env variables
<clever> yeah
<clever> and installPhase will do make install
<clever> buildPhase will run make
<clever> configurePhase will run ./configure if it exists
<clever> patchPhase will apply every patch in $patches
<clever> unpackPhase will unpack (or copy) $src to ., and then cd into the directory it made
<clever> and you can just set src and name and your done
<clever> for a lot of packages, the default phases work fine
<clever> Fare: just keep track of what directory your in and cd .. where needed
<clever> Fare: this for loop will eval each phase in turn
<clever> this is all ran in the same bash
<clever> Fare: oh, and do "set -x" in the earliest phase you control, then youll get a lot more debug info
<clever> Fare: it should be in the same directory as buildPhase
<clever> Fare: run pwd and ls -lh first
<clever> but you need to translate the configure script and Makefile into a nix expression first
<clever> Fare: basicaly, one .o file for every derivation, depending on a minimal subset of the source
<clever> Fare: i was experimenting with that in https://github.com/cleverca22/nix-tests/blob/master/make.nix
<clever> Fare: yes
<clever> Judson: you probably want to set just name
<clever> Judson: you set pname, so it must be a valid name in the gems attrset
<clever> Judson: something went wrong computing the name attribute, either builderEnv needs extra info your not giving it, or you need to set name directly
<clever> in the case of nix itself, nix is the stable version, and nixUnstable is newer, but not yet stable
<clever> git checkout <branchname>
<clever> git checkout <commitid>
<clever> kiloreux: that tells it to look for nixpkgs in nixpkgs, as in, $HOME/.nix-defexpr/channels/nixos-17.03/nixpkgs/nixpkgs must exist
<clever> sdll: when making a PR, you can just add yourself to https://github.com/NixOS/nixpkgs/blob/master/lib/maintainers.nix
<clever> Fare: $out is set to the dir you need to install things to
<clever> one of them is an alias for the other
<clever> Fare: users.users.root, just like all the other users
<clever> gchristensen: which doesnt contain Gtk in any filename
<clever> gchristensen: oh, it does an ls of /nix/store/hv3mr7wkybgg8dxhqs4pfmcplspb5rp7-gobject-introspection-1.50.0/lib/girepository-1.0
<clever> what about just giving gdb the absolute path to the debug info?
<clever> nix-env will usualy overwrite the other libuv with libuv.debug
<clever> dash: try building it with :b in nix-repl, and then inspect each output to confirm where the debug info is
<clever> dash: i have been thinking about a plugin of some kind in gdb, that would lookup the .debug outputs in the .drv files, and then fetch it from the binary cache
<clever> dash: you probably need to add "debug" to meta.outputsToInstall
<clever> gchristensen: its probably over in here
<clever> open("/nix/store/hv3mr7wkybgg8dxhqs4pfmcplspb5rp7-gobject-introspection-1.50.0/lib/libgirepository-1.0.so.1", O_RDONLY|O_CLOEXEC) = 3
<clever> gchristensen: and it seems that the implementation of enumerate_versions is written in c!
<clever> Binary file site-packages/gi/_gi.cpython-35m-x86_64-linux-gnu.so matches
<clever> :)
<clever> gchristensen: i'm trying to import this from the python repl, but its relative to another file i think
<clever> 45 from ._gi import Repository
<clever> gchristensen: little rusty with python imports, cant get access to the repository object
<clever> sdll: copy the entire derivation and just edit the copy, thats the simplest one
<clever> gchristensen: and it came from here: repository = Repository.get_default()
<clever> sdll: overrideAttrs has the same api and can usualy just be swapped in
<clever> yep
<clever> Acou_Bass: and the auto-upgrade only updates the channels on root
<clever> Acou_Bass: yep, every user has his own set of channels
<clever> gchristensen: it looks like repository.enumerate_versions(namespace) returned null
<clever> Acou_Bass: you will probably want to delete the nixos on the non-root user
<clever> ValueError: Namespace Gtk not available
<clever> Acou_Bass: you added channels called nixos to both your user and root, compare "nix-channel --list" and "sudo nix-channel --list"
<clever> gchristensen: i see the error msg, now to figure out why
<clever> copying 99 missing paths (74.74 MiB) to ‘builder@192.168.144.1’...
<clever> gchristensen: far faster to reuse the same clone and build up dozens of remotes over the years
<clever> sdll: should be the same as in mine, pathlib.overrideDerivation (old: { src = fetchsomething; });
<clever> gchristensen: [clever@amd-nixos:~/apps/nixpkgs]$ git remote add grahamc https://github.com/grahamc/nixpkgs.git
<clever> sdll: .overrideDerivation is an attribute on all derivations
<clever> sdll: you can also use pythonpackage.overrideDerivation 90% of the time
<clever> gchristensen: gist what you have and i can look at it
<clever> sdll: you can also change things, as long as it doesnt break stuff and has a good reason
<clever> sdll: then it will not conflict with the original
<clever> sdll: but you could name your override something like foo5 = foo.override.... { src = fetch ver5; };
<clever> sdll: python-packages.nix is a bit different, most of the attributes in it are exposed to the world
<clever> sdll: so it only has an effect on toxvpn and nothing else
<clever> sdll: this creates an override against toxcore, but the override is never exposed to the rest of nixpkgs
<clever> m3tti: the stable channels are a snapshot made every ~6 months
<clever> ah
<clever> but the entire array was offline
<clever> the monitoring stuff i had setup said that all the machines could reach eachother (same datacenter)
<clever> which reminds me, one crappy datacenter ive used in the past had a network outage
<clever> or if every host has matching gaps in the graphs
<clever> for my monitoring stuff, i only notice outages of the monitoring system if i either cant pull up the perf graphs
<clever> octe: yep
<clever> Filystyn: a quick check on this end says that the openscad package contains a openscad binary
<clever> Filystyn: then look in result/bin/ with ls
<clever> Filystyn: one thing i sometimes do, nix-build '<nixpkgs>' -A foo
<clever> octe: then the rpath will stay bloated, and may just work
<clever> octe: and it cant detect the dlopen usage
<clever> octe: dlopen also relies on rpath, but the fixup phase will strip anything that ldd says isnt required
<clever> octe: but if dlopen is in use, things can break more
<clever> octe: if your compiling from source, gcc will add everything to the rpath for you and LD_LIBRARY_PATH shouldnt be needed
<clever> Infinisil: or write a default.nix using stdenv_32bit.mkDerivation, and load it without -p
<clever> Infinisil: nix-shell -p stdenv_32bit might get most of it
<clever> 2015-10-02 16:29:43< kmicu> joelmo: I understand that you want to provide an easy way to use VSTs, but we cannot just grab commercial software and distribute it. Did you ask *Stainberg* if they are legally ok with what you are proposing?
<clever> the PR was rejected: https://github.com/NixOS/nixpkgs/pull/10006
<clever> which you could then add as a buildInput for lmms
<clever> it would need requireFile to even package vst headers
<clever> so its imposible to open-source any code that interfaces with it
<clever> octe: the license around VST stuff is absurd, you cant even make the .h files public
<clever> octe: something else that ive seen before that i'm not sure how it would fit into nix
<clever> ah, the last guy i was helping was dealing with some pre-built VST stuff
<clever> 2017-03-19 12:40:28< gbbrt> clever: hm, I see.. I'm trying to get some multi-lib stuff for this audio software working (bitwig) and couldn't get patchelf on the 32bit parts to work for me
<clever> need to add it on line 1, where stdenv currently is
<clever> octe: try using stdenv_32bit.mkDerivation and see if that does anything differently
<clever> ah, its probably using a 32bit wine to load 32bit VST plugins
<clever> SET(STATUS_VST "not found, please install (lib)wine-dev (or similar) - 64 bit systems additionally need gcc-multilib and g++-multilib")
<clever> ah, VST again
<clever> octe: would anything be lost by forcing it to go all 64bit?
<clever> octe: is it normal for it to try to do a 32bit build on a 64bit machine?
<clever> octe: can you gist the expression you have so far?
<clever> i am seeing some copies on a 2nd machine
<clever> $ find /nix/store/ -name stubs-32.h
<clever> /nix/store/5gri94hp1d5yvbnag2247bkvw85g8wsl-glibc-2.24-dev/include/gnu/stubs-32.h
<clever> simpson: i'm not seeing it in my copies of glibc.dev
<clever> rcschm: sounds like you did ${git} rather then ${git}/bin/git
<clever> rcschm: nearly everything is under pkgs.
<clever> rcschm: yeah
<clever> rcschm: ${git}/bin/git and ${gnused}/bin/sed i believe
<clever> then i edit the source under foo, and "diff -ur foo-orig foo"
<clever> i generaly do cd .., cp -r foo foo-orig
<clever> and often, -r as well, since your applying it to the root of the source
<clever> jluttine: it needs to be "diff -u"
<clever> and like LnL said, nix-build will read default.nix from the current dir if you done give a path
<clever> nix-build ~/apps/nixpkgs -A hello
<clever> you can also just put in a normal path
<clever> yeah
<clever> betaboon: nix-build '<nixpkgs>' -A hello
<clever> unable to reproduce on the main desktop, odd
<clever> gchristensen: i think vim_configurable may actualy be broken though, via a broken ruby, need to confirm on another machine
<clever> double the overrides!
<clever> gchristensen: i had nixpkgs.config = { packageOverrides = import ./config.nix; };, and config.nix itself contained { packageOverrides = ....; }
<clever> Filystyn: systemctl status xinetd
<clever> gchristensen: no idea how, but that breaks everything
<clever> gchristensen: yep that was it, nixpkgs.config.packageOverrides is a lamda, that returns { packageOverrides = lamda; }!
<clever> gchristensen: oh, on closer inspection, i think i made a typo in my package overrides
<clever> gchristensen: of note is lines 19, 20, 21, and 31
<clever> gchristensen: do you happen to know about shadow failing to eval on nixos-unstable? https://gist.github.com/cleverca22/4849ccda7deb3e6b6aef9e54ec0562a0
<clever> no need to install it anywhere else
<clever> Filystyn: nixos runs xinetd in a systemd unit, and passses it the absolute path to the config file
<clever> Filystyn: wont do what you want
<clever> or just test against a channel and hope when master unbreaks, your package still works
<clever> back up a bit and test against a slightly older master
<clever> Infinisil: you usualy want to test on master, to make sure its not going to already be broken by other things
<clever> Infinisil: the release-17.03 on nixpkgs is what hydra tests, and may become the future channel version
<clever> Infinisil: the nixos-17.03 branch of the nixpkgs-channels repo is synced to the channel
<clever> Filystyn: did you use exactly what i typed?
<clever> Filystyn: i didnt have a test= in my example
<clever> Infinisil: is the path pointing to nixpkgs directly, or a something containing nixpkgs?
<clever> Filystyn: try services.xinetd.services = [ { name="foo"; port = 1234; } ];
<clever> attempt to call something which is not a function but a set, at /nix/store/3c56j70s96kf9nd90r3h12g7y7c3s38q-nixos-17.09pre107265.0afb6d789c/nixos/lib/trivial.nix:88:67
<clever> while evaluating the attribute ‘pkgs’ at /nix/store/3c56j70s96kf9nd90r3h12g7y7c3s38q-nixos-17.09pre107265.0afb6d789c/nixos/pkgs/development/interpreters/python/cpython/2.7/default.nix:201:7:
<clever> strange, shadow depends on gnome-doc-utils, and gnome-doc-utils fails to even eval
<clever> i think server must be specified, to tell xinetd what to run
<clever> Filystyn: what error does it give?
<clever> no idea how that fixed it then
<clever> gchristensen: ah yeah, i see it running lsdiff in the postfetch to clean it up
<clever> gchristensen: the --name at the end may be to deal with that
<clever> simendsjo: if the change has been backported to the stable channel, then it should fix itself in time, and you only need the above command to speed things up
<clever> gchristensen: acording to the chat logs from yesterday, it did fix the issue
<clever> 2017-05-13 15:27:28< blogle> Cudatoolkit is now building so looks like a success!
<clever> 2017-05-13 15:25:14< blogle> thanks, going to give it a go now
<clever> simendsjo: this should fix the 404
<clever> 2017-05-13 15:24:24 < dfranke> nix-prefetch-url https://git.archlinux.org/svntogit/packages.git/plain/repos/extra-x86_64/kernel_4.10.patch?h=packages/nvidia --name nvidia
<clever> sdll: and for extra confusion, ZMQCompleter has nothing to do wit zmq!
<clever> sdll: i'm guessing that the zmq version may be out of date
<clever> unlmtd: not sure where the simplest point to change it is right now
<clever> unlmtd: i think thats related to the work being done in this issue: https://github.com/NixOS/nixpkgs/issues/6221
<clever> and the entire set is returned by default.nix, so you can use -A to refer to any of them
<clever> sdll: with this, you can now define a set of closely inter-connected packages between lines 8&11, and they can depend on eachother easily
<clever> sdll: the default.nix needs to be properly formated, let me add more to the gist
<clever> and then nix-shell gives me an env with just generator and protobuf
<clever> so i can aim nix-shell at it with nix-shell -A generator-env
<clever> in that gist, env.nix is a dummy package, that needs generator and protobuf to "build"
<clever> sdll: nix-shell -A will give you an environment suitable for building whatever you pointed it at
<clever> sdll: something similiar that ive done recently: https://gist.github.com/cleverca22/bb103d600ac7cc737e7ab009ad6c48da
<clever> but ive since ditched gentoo on that machine
<clever> i was doing the oposite when i started, i was including the nixos config into a gentoo grub.conf
<clever> so maybe having an extra profile for a recovery installer, which will get its own entry in the grub
<clever> but for stability, you dont want nixos-rebuild to update it constantly
<clever> if you drop this initrd and kernel into /boot, and give them an entry in grub, you can boot the install media without needing a cd/usb
<clever> i was also thinking about inserting a 2nd nixos based image in there, that nixos-rebuild wont update every time
<clever> so that would be an ideal place to sign the kernels
<clever> and it deals with copying kernels to /boot if needed
<clever> this script gets ran every time nixos-rebuild needs to update the grub.conf file
<clever> you would either need the install-grub area to sign things after the build, or make the key world-readable by putting it into the store
<clever> yeah
<clever> hmmm, yeah, not sure if ipxe is able to handle a local filesystem
<clever> an ssl cert is embeded into the ipxe binary, and all files it executes must be signed
<clever> sphalerite: closest i have is this custom solution in ipxe: https://github.com/cleverca22/not-os/blob/master/ipxe.nix

2017-05-13

<clever> should work the same with python3.withPackages
<clever> though i would have expected buildPythonPackage to handle this for the user
<clever> alphor: and then make sure the script uses something like #!/usr/bin/env python
<clever> alphor: i'm thinking add this to the start of buildInputs, (python2.withPackages (ps: [ ps.requests2 cachecontrol msgpack ])
<clever> ah
<clever> yeah, that works here too
<clever> Gravious: this is able to import requests
<clever> [clever@amd-nixos:~]$ nix-shell -p '(python2.withPackages (pkgs: [ pkgs.requests ]))'
<clever> Gravious: what if you got a shell with python2.withPackages (pkgs: [ pkgs.requests ]) i think it was
<clever> sdll: for example, this is the configuration from one of my raspberry pi's, https://gist.github.com/cleverca22/6d408ff69eab1680bef9
<clever> sdll: i have some fragments of it in various gist files
<clever> cant think of anything else that would be doing that
<clever> and no other conflicting set's show up afterwards?
<clever> strange
<clever> does it work if you manualy run that in a shell?
<clever> it makes bash print every command it runs
<clever> yeah
<clever> sdll: try putting a set -x in .bashrc
<clever> sdll: in my machine, xterm's shell runs .bashrc
<clever> put an echo statement in each
<clever> sdll: id check first to see if .profile or .bashrc is being ran
<clever> sdll: and there is also the difference between normal shells and login shells to keep in mind
<clever> sdll: programs.bash.shellInit winds up in /etc/profile
<clever> nixos/modules/system/activation/activation-script.nix: system.activationScripts.stdio =
<clever> lib/strings-with-deps.nix: stringAfter = deps: text: { inherit text deps; };
<clever> ah, this one is a bit different
<clever> nixos/modules/config/shells-environment.nix: system.activationScripts.binsh = stringAfter [ "stdio" ]
<clever> ive seen that used in the activation scripts
<clever> i keep meaning to open a pr and forget about it
<clever> so if you try to both enable and disable that thing, it silently ignores the disable
<clever> and the default for booleans is just the or operation
<clever> and this reminds me, there is a boolean option in nixos somewhere, i forget where now, that lacks a type
<clever> and mkDefault is priority 1000
<clever> ah, and mkForce is just a priority 50 override
<clever> something must be doing that, before it gets passed to the type merge
<clever> nixos/modules/services/editors/emacs.nix: EDITOR = mkOverride 900 "${editorScript}/bin/emacseditor";