<clever>
same, i have some notes from questions i asked before, but havent done much
<clever>
LnL: i think --option substituters could be used to treat /nix/store as a binary cache, when doing a build that targets /tmp/nix-cache/nix/store/
<clever>
and you can then either copy it to /nix/store, or use option substituters to implement a copy-closure thing
<clever>
LnL: yeah, this sets up a store that isnt mounted at the right spot yet, and the paths in the above cmd are wrong
<clever>
i believe the 1st example treats a store as a cache, and the 2nd example lets you act on a store that isnt at /nix/store yet (chroot'ing for you)
<clever>
it sounds like all store actions will go to that dir, and not /nix/store/
<clever>
LnL: oh, interesting, not sure what that will do exactly, will need to play with it
<clever>
LnL: oh, and then nix-push what you want to save into that, so travis can tar it back up
<clever>
i also saw a trick in the github issues many months ago, where you first nix-build the kernel, then nix-shell into the kernel, so you can use its deps and $out to build modules
<clever>
nix-shell also wont delete the outputs, so you can shell into the failing derivation, and then grep for $out in $lib
<clever>
domenkozar: the above also helps greatly in fixing reference cycles in multiple output derivations
<clever>
domenkozar: and i have found uses for that, a failed build leaves the $out intact, and then i can investigate logs it left there
<clever>
and because it refuses to use it, things like ~/.nix-profile/ wont refer to it
<clever>
i believe it will also refuse to use invalid paths, and remove them if they are in the way of a future build
<clever>
and it may stop updating things like the channel or nix version
<clever>
LnL: but if you cache everything, including db.sqlite, it may get confused when travis tries to install nix again
<clever>
and nix doesnt manage ~/.stack/, so it never cleans up the broken ELF's
<clever>
and when nix updates glibc, the binaries in the cache become invalid
<clever>
binaries made by stack in ~/.stack/ can refer to the ld.so in the store
<clever>
it also accepts a branch name, and can detect the repo from the current dir
<clever>
Usage: travis logs [NUMBER] [OPTIONS]
<clever>
oh, and the travis cli tools can probably help to bypass a lot of the browser being crap problems
<clever>
domenkozar: my core2duo laptop took over 5 minutes just to load an appveyor log a week or 2 ago
<clever>
i think that module is to let you use a samba password via pam
<clever>
i think rpcbind just lets you lookup the port behind a named service
<clever>
simpson: what about rpcbind?
<clever>
dash: and googles 8.8.8.8 keeps randomly claiming the domain doesnt exist
<clever>
dash: it has even returned aaaa records in response to an a query, with no ipv6 setup
<clever>
dash: so it can return a records when the client asked for srv
<clever>
dash: one users router, doesnt use the record type (a, aaaa, srv) as a key in the cache
<clever>
dash: i recently switched one of my services to SRV, but now i'm finding new fun bugs
<clever>
yeah, that has to be done for ipfs
<clever>
i just pick a random number between 1024 and 65535 when i start a project
<clever>
ipfs should probably get a dedicated port
<clever>
i suspect its failing to contact the daemon
<clever>
and just silently trying to access it directly
<clever>
joepie91: so it can compute the key names for everything in one block, before the config value is known
<clever>
joepie91: i think its more about the name of the key not depending on the config or options sets
<clever>
joepie91: mainly the top level ones i believe
<clever>
joepie91: and to prevent infinite recursion, the key names in the config set must be static, so it can compute them and know which module to route the requests into
<clever>
joepie91: so you are getting your own return value as an argument
<clever>
joepie91: nixos will take the .config returned by every module (after recursively following imports), and merge them all together, then pass that merged result as the config argument, to every module
<clever>
joepie91: i dont think nixos supports this kind of dynamic module creation, goes a bit farther then what it was designed for
<clever>
joepie91: and the stack trace wouldnt point to line 26, it would point to the internal nixos code, that tries to run the function
<clever>
joepie91: nix doesnt apply functions when they are in a list like that
<clever>
joepie91: oh, line 26 of networks/default.nix is also wrong, that is a list containing a function and a set
<clever>
joepie91: mostly so you can just get by with a single function at the top level of node-application.nix
<clever>
then it would receive all arguments a module takes, plus some extra
<clever>
joepie91: maybe something like this in pastebin-steam.nix, { pkgs, ... }@args: import ./node-application.nix (args // { tarball ... })
<clever>
its not being passed in as an argument
<clever>
joepie91: i just noticed, how is node-application.nix even getting a reference to config?
<clever>
and then it could possibly auto-generate all of the config and options
<clever>
joepie91: you could get the same effect by doing something like nodejs.services.pastebin-stream = { tarball = ... ; }; i think
<clever>
joepie91: the key to how it works is the submodule on line 119, and the map on line 117
<clever>
joepie91: this code lets you do services.openvpn.servers.<name> = { ... }; and it will auto-generate multiple service units
<clever>
the travis test is being derpy, i think its trying to rebuild the entire kernel
<clever>
ah, and that is in the default XDG_CONFIG_DIRS, should work then
<clever>
yeah
<clever>
bkchr: they will instead land in either /run/current-system/sw/etc/xdg/autostart or ~/.nix-profile/etc/xdg/autostart
<clever>
bkchr: and i dont expect things in $out/etc/xdg/autostart to land in the real /etc/xdg/autostart
<clever>
bkchr: dont have any push access here
<clever>
vaibhavsagar: i believe it runs Setup.hs, which imports cabal
<clever>
giving both --datadir and --docdir appears to prevent the issue
<clever>
but if your datadir doesnt contain ghc, the docs wind up in --prefix
<clever>
if your --datadir contains ghc, the docs appear inside it
<clever>
domenkozar: but its an odd bug to keep in mind, which may crop up again, given that cabal behaves differently if "ghc" is present in the --datadir or not
<clever>
domenkozar: i dont remember which package it was on, but it was fixed by just always passing some enable flag to configure, i discovered it when reading the comments in that nix file
<clever>
yeah
<clever>
so it wont ask pkg-config for the real one
<clever>
if it finds psql in the cflags, it assumes you already setup the -I path
<clever>
and due to hashes, psql can appear in the cflags without being the psql include path
<clever>
something in nixpkgs will auto-detect if psql is i the cflags, to determine if it needs to run pkg-config or not
<clever>
bennofs: also, i have seen a bug because the word "psql" appeared in the hash
<clever>
i think nix avoids ones that could make the hash confusing
<clever>
bennofs: its a non-standard form of base32
2017-07-11
<clever>
for example, not even root can delete an old /var/empty/ when cleaning an old drive out
<clever>
LnL: some filesystems have extended attributes,and the immutable bit makes something read-only, even to root
<clever>
the value of foo is bar, which is baz, which is foo, which is bar, which is baz, which is foo, which is bar,which is baz, which is foo, which is bar,which is baz, which is foo, which is bar,
<clever>
pretty obvious why it has infinite recursion
<clever>
also figured out the typo in my example
<clever>
36
<clever>
[clever@amd-nixos:~]$ nix-instantiate --eval -E '{ x }: x*x' --arg x 6
<clever>
can you gist the contents of that file?
<clever>
what is the error?
<clever>
it should have a --show-trace
<clever>
though in --eval mode, it will only eval, and not run
<clever>
<LAMBDA>
<clever>
[clever@amd-nixos:~]$ nix-instantiate --eval -E 'x: x*x' --argstr x 6
<clever>
--arg and --argstr are also available, to pass values to the file
<clever>
ah, --eval prints the value, and -E lets you run a string without having a file
<clever>
that channel then loads config.nix, which mutates the package set
<clever>
the nixos. tells it which channel to load
<clever>
erlandsona: you need nixos.erlandsona
<clever>
and a directory is just a list of names and objectid's
<clever>
every object in git is stored as sha1(value)=value, all objects have a type, and sometimes a size prepended to the value
<clever>
and everything in git is sha1, which is close to becoming useless
<clever>
so the treeid doesnt even exist
<clever>
it just builds a url to the .tar.gz archive
<clever>
and then you have things like fetchFromGithub, that entirely ignore the git protocol
<clever>
you must start a clone from a commit that is at the tip of a branch
<clever>
you could, but git doesnt allow you to clone a random tree of objects
<clever>
nix will enforce it always being the exact same source
<clever>
one of the key things with fixed-output derivations, is that you dont have to trust the repo or the network
<clever>
and the treeid is a hash over a list of (filename, objectid) (the contents of the root folder)
<clever>
catern: the commit is a hash over (commitmsg, parent commit, treeid)
<clever>
catern: the problem is that git is a bit of a blockchain design, and to confirm the files you cloned are from that commit, you have to clone the entire history
<clever>
/bin/sh=<pathtosh> <pathtoglibc> ... <the full closure of sh>
<clever>
gchristensen: after reading the source i linked above, i think its enough to setup build-sandbox-paths just like on nixos