2017-05-15
00:30
<
clever >
johnramsden: most vm stuff will create a tun/tap device linked to the guest, and then add that device to the bridge
00:25
<
clever >
johnramsden: yeah, that looks good
00:20
<
clever >
nix-build -E 'with import <nixpkgs>{}; callPackage ./default.nix'
00:19
<
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
00:18
<
clever >
and now you have infinite recursion
00:16
<
clever >
is there anything about arangodb in it?
00:16
<
clever >
what is in that file?
00:15
<
clever >
rcschm: do you have a ~/.nixpkgs/config.nix file?
00:15
<
clever >
-A doesnt work like that
00:14
<
clever >
rcschm: what is in config.nix?
00:14
<
clever >
johnramsden: meant to say //
00:13
<
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
00:13
<
clever >
johnramsden: lib.recursiveUpdate takes 2 attrsets and does similiar to {}
00:12
<
clever >
johnramsden: there is another function that does a deep merge
00:12
<
clever >
johnramsden: and // overwrites the entire defaultGateway attribute, clearing address
00:12
<
clever >
johnramsden: and line 25-32 contains a defaultGateway = { interface = "br0"; };
00:11
<
clever >
johnramsden: the line 18-25 derivation contains a defaultGateway = { address = "..."; }; attribute
00:11
<
clever >
johnramsden: line 26 is the problem
00:08
<
clever >
and where did you put that file?
00:07
<
clever >
can you gist the nix file your editing?
00:01
<
clever >
johnramsden: networking = { } // (lib.optionalAttrs useBridge {});
2017-05-14
23:59
<
clever >
johnramsden: try wrapping it with ( and ) to enforce the order of operations
23:58
<
clever >
rcschm: nix-env will make a mess of your profile and waste a lot more disk space in the long run
23:58
<
clever >
rcschm: and also, you want to use nix-build for testing, not nix-env
23:57
<
clever >
rcschm: what is the exact command you are running, and what directory is it being ran in?
23:56
<
clever >
and i think false turns into an empty string, its weird
23:55
<
clever >
i think true casts to 1 when that happens
23:55
<
clever >
Fare: the attributes inside a derivation get cast down to a string, and dontStrip is then checked by a bash script for truthiness
23:53
<
clever >
johnramsden: in the snmpd.nix example i linked, the passwords value is available everywhere after line 3
23:52
<
clever >
Fare: yeah
23:51
<
clever >
rcschm: yeah, line 21/22
23:50
<
clever >
rcschm: we need to first look at the original derivation, and know what its doing
23:50
<
clever >
the {....} attrset is the main value in the file, and it has been prefixed by a let block
23:49
<
clever >
johnramsden: any place you can put a value, you can also do this: let <key=value pairs>; in <value>
23:48
<
clever >
rcschm: i think the patch list on the original arangodb derivation is having the problem
23:45
<
clever >
can you gist the full output of nix-build?
23:44
<
clever >
something needs to start a build of v8
23:43
<
clever >
the build directory is missing
23:43
<
clever >
ah, its not a git submodule
23:42
<
clever >
the hash will need to be updated as well
23:41
<
clever >
and it will get all of the submodules for you
23:41
<
clever >
set fetchSubmodules=true; inside the fetchFromGitHub call
23:41
<
clever >
using fetchFromGitHub?
23:40
<
clever >
which fetch function are you using?
23:40
<
clever >
is it on github and using git submodules?
23:36
<
clever >
just pop in the right url and point nix-build at it
23:33
<
clever >
if you just put cmake in the buildInputs and unset builder=, then cmake will just magicaly do everything for you
23:33
<
clever >
you almost never want to use builder= in a derivation
23:31
<
clever >
can you gist the nix expression?
23:31
<
clever >
what happens when you run nix-build on that expression?
23:30
<
clever >
th cmake setup hook will deal with running cmake for you
23:30
<
clever >
rcschm: start by setting src, name, and buildInputs = [ cmake ];
23:21
<
clever >
i had to make $out and chown them to the right user, before a non-root make install, to even reproduce the problem
23:20
<
clever >
and you cant just sudo nix-shell, because it now has write to its buildInputs and doesnt fail
23:20
<
clever >
you cant just "make install" in a nix-shell, because it lacks write to $out
23:20
<
clever >
for example, one of the qt modules on darwin, tries to write to one of its input directories, which are read-only
23:19
<
clever >
MichaelRaskin: though i have seen some rather hard to debug problems in the installPhase
23:18
<
clever >
they tried to make their own pure build system
23:18
<
clever >
and it lost NIX_CFLAGS_COMPILE
23:18
<
clever >
MichaelRaskin: only time ive seen it fail spectacularly, is when a python build system steralized the env variables
23:14
<
clever >
and installPhase will do make install
23:14
<
clever >
buildPhase will run make
23:14
<
clever >
configurePhase will run ./configure if it exists
23:14
<
clever >
patchPhase will apply every patch in $patches
23:14
<
clever >
unpackPhase will unpack (or copy) $src to ., and then cd into the directory it made
23:13
<
clever >
and you can just set src and name and your done
23:13
<
clever >
for a lot of packages, the default phases work fine
23:12
<
clever >
Fare: just keep track of what directory your in and cd .. where needed
23:10
<
clever >
Fare: this for loop will eval each phase in turn
23:10
<
clever >
this is all ran in the same bash
23:08
<
clever >
Fare: oh, and do "set -x" in the earliest phase you control, then youll get a lot more debug info
23:07
<
clever >
Fare: it should be in the same directory as buildPhase
23:07
<
clever >
Fare: run pwd and ls -lh first
22:22
<
clever >
but you need to translate the configure script and Makefile into a nix expression first
22:22
<
clever >
Fare: basicaly, one .o file for every derivation, depending on a minimal subset of the source
22:01
<
clever >
Judson: you probably want to set just name
22:01
<
clever >
Judson: you set pname, so it must be a valid name in the gems attrset
21:56
<
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
21:44
<
clever >
in the case of nix itself, nix is the stable version, and nixUnstable is newer, but not yet stable
21:32
<
clever >
git checkout <branchname>
21:31
<
clever >
git checkout <commitid>
21:29
<
clever >
kiloreux: that tells it to look for nixpkgs in nixpkgs, as in, $HOME/.nix-defexpr/channels/nixos-17.03/nixpkgs/nixpkgs must exist
21:04
<
clever >
Fare: $out is set to the dir you need to install things to
20:23
<
clever >
one of them is an alias for the other
20:22
<
clever >
Fare: users.users.root, just like all the other users
19:35
<
clever >
gchristensen: which doesnt contain Gtk in any filename
19:35
<
clever >
gchristensen: oh, it does an ls of /nix/store/hv3mr7wkybgg8dxhqs4pfmcplspb5rp7-gobject-introspection-1.50.0/lib/girepository-1.0
19:34
<
clever >
what about just giving gdb the absolute path to the debug info?
19:34
<
clever >
nix-env will usualy overwrite the other libuv with libuv.debug
19:32
<
clever >
dash: try building it with :b in nix-repl, and then inspect each output to confirm where the debug info is
19:30
<
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
19:29
<
clever >
dash: you probably need to add "debug" to meta.outputsToInstall
19:28
<
clever >
gchristensen: its probably over in here
19:28
<
clever >
open("/nix/store/hv3mr7wkybgg8dxhqs4pfmcplspb5rp7-gobject-introspection-1.50.0/lib/libgirepository-1.0.so.1", O_RDONLY|O_CLOEXEC) = 3
19:27
<
clever >
gchristensen: and it seems that the implementation of enumerate_versions is written in c!
19:27
<
clever >
Binary file site-packages/gi/_gi.cpython-35m-x86_64-linux-gnu.so matches
19:23
<
clever >
gchristensen: i'm trying to import this from the python repl, but its relative to another file i think
19:23
<
clever >
45 from ._gi import Repository
19:21
<
clever >
gchristensen: little rusty with python imports, cant get access to the repository object
19:19
<
clever >
sdll: copy the entire derivation and just edit the copy, thats the simplest one
19:17
<
clever >
gchristensen: and it came from here: repository = Repository.get_default()
19:17
<
clever >
sdll: overrideAttrs has the same api and can usualy just be swapped in
19:16
<
clever >
Acou_Bass: and the auto-upgrade only updates the channels on root
19:16
<
clever >
Acou_Bass: yep, every user has his own set of channels
19:15
<
clever >
gchristensen: it looks like repository.enumerate_versions(namespace) returned null
19:14
<
clever >
Acou_Bass: you will probably want to delete the nixos on the non-root user
19:14
<
clever >
ValueError: Namespace Gtk not available
19:13
<
clever >
Acou_Bass: you added channels called nixos to both your user and root, compare "nix-channel --list" and "sudo nix-channel --list"
19:13
<
clever >
gchristensen: i see the error msg, now to figure out why
19:11
<
clever >
copying 99 missing paths (74.74 MiB) to ‘builder@192.168.144.1’...
19:08
<
clever >
gchristensen: far faster to reuse the same clone and build up dozens of remotes over the years
19:08
<
clever >
sdll: should be the same as in mine, pathlib.overrideDerivation (old: { src = fetchsomething; });
19:06
<
clever >
sdll: .overrideDerivation is an attribute on all derivations
19:05
<
clever >
sdll: you can also use pythonpackage.overrideDerivation 90% of the time
19:05
<
clever >
gchristensen: gist what you have and i can look at it
18:47
<
clever >
sdll: you can also change things, as long as it doesnt break stuff and has a good reason
18:46
<
clever >
sdll: then it will not conflict with the original
18:45
<
clever >
sdll: but you could name your override something like foo5 = foo.override.... { src = fetch ver5; };
18:45
<
clever >
sdll: python-packages.nix is a bit different, most of the attributes in it are exposed to the world
18:41
<
clever >
sdll: so it only has an effect on toxvpn and nothing else
18:41
<
clever >
sdll: this creates an override against toxcore, but the override is never exposed to the rest of nixpkgs
18:36
<
clever >
m3tti: the stable channels are a snapshot made every ~6 months
18:16
<
clever >
but the entire array was offline
18:16
<
clever >
the monitoring stuff i had setup said that all the machines could reach eachother (same datacenter)
18:16
<
clever >
which reminds me, one crappy datacenter ive used in the past had a network outage
18:15
<
clever >
or if every host has matching gaps in the graphs
18:15
<
clever >
for my monitoring stuff, i only notice outages of the monitoring system if i either cant pull up the perf graphs
18:10
<
clever >
Filystyn: a quick check on this end says that the openscad package contains a openscad binary
18:06
<
clever >
Filystyn: then look in result/bin/ with ls
18:06
<
clever >
Filystyn: one thing i sometimes do, nix-build '<nixpkgs>' -A foo
18:04
<
clever >
octe: then the rpath will stay bloated, and may just work
18:03
<
clever >
octe: and it cant detect the dlopen usage
18:03
<
clever >
octe: dlopen also relies on rpath, but the fixup phase will strip anything that ldd says isnt required
18:03
<
clever >
octe: but if dlopen is in use, things can break more
18:02
<
clever >
octe: if your compiling from source, gcc will add everything to the rpath for you and LD_LIBRARY_PATH shouldnt be needed
17:58
<
clever >
Infinisil: or write a default.nix using stdenv_32bit.mkDerivation, and load it without -p
17:58
<
clever >
Infinisil: nix-shell -p stdenv_32bit might get most of it
17:57
<
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?
17:52
<
clever >
which you could then add as a buildInput for lmms
17:52
<
clever >
it would need requireFile to even package vst headers
17:51
<
clever >
so its imposible to open-source any code that interfaces with it
17:51
<
clever >
octe: the license around VST stuff is absurd, you cant even make the .h files public
17:51
<
clever >
octe: something else that ive seen before that i'm not sure how it would fit into nix
17:50
<
clever >
ah, the last guy i was helping was dealing with some pre-built VST stuff
17:50
<
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
17:49
<
clever >
need to add it on line 1, where stdenv currently is
17:48
<
clever >
octe: try using stdenv_32bit.mkDerivation and see if that does anything differently
17:47
<
clever >
ah, its probably using a 32bit wine to load 32bit VST plugins
17:47
<
clever >
SET(STATUS_VST "not found, please install (lib)wine-dev (or similar) - 64 bit systems additionally need gcc-multilib and g++-multilib")
17:47
<
clever >
ah, VST again
17:46
<
clever >
octe: would anything be lost by forcing it to go all 64bit?
17:46
<
clever >
octe: is it normal for it to try to do a 32bit build on a 64bit machine?
17:43
<
clever >
octe: can you gist the expression you have so far?
17:43
<
clever >
i am seeing some copies on a 2nd machine
17:43
<
clever >
$ find /nix/store/ -name stubs-32.h
17:43
<
clever >
/nix/store/5gri94hp1d5yvbnag2247bkvw85g8wsl-glibc-2.24-dev/include/gnu/stubs-32.h
17:39
<
clever >
simpson: i'm not seeing it in my copies of glibc.dev
17:33
<
clever >
rcschm: sounds like you did ${git} rather then ${git}/bin/git
17:29
<
clever >
rcschm: nearly everything is under pkgs.
17:29
<
clever >
rcschm: yeah
17:07
<
clever >
rcschm: ${git}/bin/git and ${gnused}/bin/sed i believe
14:46
<
clever >
then i edit the source under foo, and "diff -ur foo-orig foo"
14:46
<
clever >
i generaly do cd .., cp -r foo foo-orig
14:40
<
clever >
and often, -r as well, since your applying it to the root of the source
14:40
<
clever >
jluttine: it needs to be "diff -u"
14:07
<
clever >
and like LnL said, nix-build will read default.nix from the current dir if you done give a path
14:07
<
clever >
nix-build ~/apps/nixpkgs -A hello
14:07
<
clever >
you can also just put in a normal path
14:04
<
clever >
betaboon: nix-build '<nixpkgs>' -A hello
13:44
<
clever >
unable to reproduce on the main desktop, odd
13:42
<
clever >
gchristensen: i think vim_configurable may actualy be broken though, via a broken ruby, need to confirm on another machine
13:37
<
clever >
double the overrides!
13:37
<
clever >
gchristensen: i had nixpkgs.config = { packageOverrides = import ./config.nix; };, and config.nix itself contained { packageOverrides = ....; }
13:35
<
clever >
Filystyn: systemctl status xinetd
13:33
<
clever >
gchristensen: no idea how, but that breaks everything
13:32
<
clever >
gchristensen: yep that was it, nixpkgs.config.packageOverrides is a lamda, that returns { packageOverrides = lamda; }!
13:31
<
clever >
gchristensen: oh, on closer inspection, i think i made a typo in my package overrides
13:30
<
clever >
gchristensen: of note is lines 19, 20, 21, and 31
13:29
<
clever >
no need to install it anywhere else
13:29
<
clever >
Filystyn: nixos runs xinetd in a systemd unit, and passses it the absolute path to the config file
13:29
<
clever >
Filystyn: wont do what you want
13:14
<
clever >
or just test against a channel and hope when master unbreaks, your package still works
13:14
<
clever >
back up a bit and test against a slightly older master
13:12
<
clever >
Infinisil: you usualy want to test on master, to make sure its not going to already be broken by other things
13:07
<
clever >
Infinisil: the release-17.03 on nixpkgs is what hydra tests, and may become the future channel version
13:06
<
clever >
Infinisil: the nixos-17.03 branch of the nixpkgs-channels repo is synced to the channel
13:06
<
clever >
Filystyn: did you use exactly what i typed?
13:05
<
clever >
Filystyn: i didnt have a test= in my example
13:01
<
clever >
Infinisil: is the path pointing to nixpkgs directly, or a something containing nixpkgs?
12:57
<
clever >
Filystyn: try services.xinetd.services = [ { name="foo"; port = 1234; } ];
12:53
<
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
12:53
<
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:
12:50
<
clever >
strange, shadow depends on gnome-doc-utils, and gnome-doc-utils fails to even eval
12:24
<
clever >
i think server must be specified, to tell xinetd what to run
12:23
<
clever >
Filystyn: what error does it give?
11:38
<
clever >
no idea how that fixed it then
11:38
<
clever >
gchristensen: ah yeah, i see it running lsdiff in the postfetch to clean it up
11:37
<
clever >
gchristensen: the --name at the end may be to deal with that
11:37
<
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
11:36
<
clever >
gchristensen: acording to the chat logs from yesterday, it did fix the issue
11:36
<
clever >
2017-05-13 15:27:28< blogle> Cudatoolkit is now building so looks like a success!
11:36
<
clever >
2017-05-13 15:25:14< blogle> thanks, going to give it a go now
11:35
<
clever >
simendsjo: this should fix the 404
11:33
<
clever >
sdll: and for extra confusion, ZMQCompleter has nothing to do wit zmq!
11:33
<
clever >
sdll: i'm guessing that the zmq version may be out of date
10:53
<
clever >
unlmtd: not sure where the simplest point to change it is right now
10:47
<
clever >
and the entire set is returned by default.nix, so you can use -A to refer to any of them
10:47
<
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
10:45
<
clever >
sdll: the default.nix needs to be properly formated, let me add more to the gist
10:40
<
clever >
and then nix-shell gives me an env with just generator and protobuf
10:40
<
clever >
so i can aim nix-shell at it with nix-shell -A generator-env
10:40
<
clever >
in that gist, env.nix is a dummy package, that needs generator and protobuf to "build"
10:39
<
clever >
sdll: nix-shell -A will give you an environment suitable for building whatever you pointed it at
10:27
<
clever >
but ive since ditched gentoo on that machine
10:26
<
clever >
i was doing the oposite when i started, i was including the nixos config into a gentoo grub.conf
10:25
<
clever >
so maybe having an extra profile for a recovery installer, which will get its own entry in the grub
10:24
<
clever >
but for stability, you dont want nixos-rebuild to update it constantly
10:24
<
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
10:23
<
clever >
i was also thinking about inserting a 2nd nixos based image in there, that nixos-rebuild wont update every time
10:22
<
clever >
so that would be an ideal place to sign the kernels
10:22
<
clever >
and it deals with copying kernels to /boot if needed
10:21
<
clever >
this script gets ran every time nixos-rebuild needs to update the grub.conf file
10:21
<
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
10:19
<
clever >
hmmm, yeah, not sure if ipxe is able to handle a local filesystem
10:17
<
clever >
an ssl cert is embeded into the ipxe binary, and all files it executes must be signed
2017-05-13
23:08
<
clever >
should work the same with python3.withPackages
23:07
<
clever >
though i would have expected buildPythonPackage to handle this for the user
23:07
<
clever >
alphor: and then make sure the script uses something like #!/usr/bin/env python
23:07
<
clever >
alphor: i'm thinking add this to the start of buildInputs, (python2.withPackages (ps: [ ps.requests2 cachecontrol msgpack ])
22:21
<
clever >
yeah, that works here too
22:18
<
clever >
Gravious: this is able to import requests
22:18
<
clever >
[clever@amd-nixos:~]$ nix-shell -p '(python2.withPackages (pkgs: [ pkgs.requests ]))'
22:17
<
clever >
Gravious: what if you got a shell with python2.withPackages (pkgs: [ pkgs.requests ]) i think it was
22:15
<
clever >
sdll: i have some fragments of it in various gist files
22:13
<
clever >
cant think of anything else that would be doing that
22:11
<
clever >
and no other conflicting set's show up afterwards?
22:11
<
clever >
does it work if you manualy run that in a shell?
22:08
<
clever >
it makes bash print every command it runs
22:07
<
clever >
sdll: try putting a set -x in .bashrc
22:07
<
clever >
sdll: in my machine, xterm's shell runs .bashrc
22:06
<
clever >
put an echo statement in each
22:05
<
clever >
sdll: id check first to see if .profile or .bashrc is being ran
22:04
<
clever >
sdll: and there is also the difference between normal shells and login shells to keep in mind
22:04
<
clever >
sdll: programs.bash.shellInit winds up in /etc/profile
20:46
<
clever >
nixos/modules/system/activation/activation-script.nix: system.activationScripts.stdio =
20:44
<
clever >
lib/strings-with-deps.nix: stringAfter = deps: text: { inherit text deps; };
20:44
<
clever >
ah, this one is a bit different
20:44
<
clever >
nixos/modules/config/shells-environment.nix: system.activationScripts.binsh = stringAfter [ "stdio" ]
20:43
<
clever >
ive seen that used in the activation scripts
20:40
<
clever >
i keep meaning to open a pr and forget about it
20:39
<
clever >
so if you try to both enable and disable that thing, it silently ignores the disable
20:39
<
clever >
and the default for booleans is just the or operation
20:39
<
clever >
and this reminds me, there is a boolean option in nixos somewhere, i forget where now, that lacks a type
20:38
<
clever >
and mkDefault is priority 1000
20:37
<
clever >
ah, and mkForce is just a priority 50 override
20:36
<
clever >
something must be doing that, before it gets passed to the type merge
20:36
<
clever >
nixos/modules/services/editors/emacs.nix: EDITOR = mkOverride 900 "${editorScript}/bin/emacseditor";