2017-12-21

<clever> it just has a name and hash
<clever> nix doesnt understand git
<clever> it has to be a hash that doesnt match any file you have downloaded
<clever> asymmetric: that "wrong" hash was right for another file
<clever> if you used a rev, the filenames wouldnt have matched, and it would have missed
<clever> and both network and protocol have v1.4.0.tar.gz
<clever> the problem, is that the filename is based on the rev and hash
<clever> also, using a git rev would have been better
<clever> that causes network to build from protocol's source
<clever> so it just uses that tar
<clever> because you already have a different tar that matches that sha256
<clever> cheshircat_: try again with nix-shell --pure, does that change anything?
<clever> the sha256 of the source
<clever> it should be 1zlhyh5z0fla1yc6kwkx65ycwgmrcrkvzj8119wbkxy3xhzpwxpv
<clever> asymmetric: what is the hash on network?
<clever> cheshircat_: what params did you give nix-shell?
<clever> now*
<clever> its not building
<clever> protocol has to be added to explorer
<clever> Package 'libbitcoin-protocol', required by 'libbitcoin-client', not found
<clever> cheshircat_: is this under nix-build?
<clever> your network package is using the protocol source
<clever> and it re-uses the protocol source
<clever> so when network builds, it discovers it already has the source named by that hash
<clever> the same sha256 is on both the network and protocol
<clever> oh!
<clever> the libbitcoin-network package contains a libbitcoin-protocol.pc
<clever> oh
<clever> Name: libbitcoin-protocol
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ cat result/lib/pkgconfig/libbitcoin-protocol.pc
<clever> Package 'libzmq', required by 'libbitcoin-protocol', not found
<clever> asymmetric: the error seems pretty obvious to me
<clever> Package 'libbitcoin', required by 'libbitcoin-client', not found
<clever> builder for ‘/nix/store/d349wy9vs4axj4503vkr1rasqymbxwis-libbitcoin-explorer-3.4.0.drv’ failed with exit code 1
<clever> thats part of gcc, so it should just work
<clever> and if you read the compiled configure script?
<clever> asymmetric: and how does configure search for it?
<clever> asymmetric: which dependency is it not finding?

2017-12-20

<clever> that can be done with almost anything in /etc
<clever> nixos will overwrite it with a symlink next time you switch or boot
<clever> Lisanna: aka, replace the symlink with a normal file, and edit away
<clever> Lisanna: another trick, cd /etc/nix ; cat nix.conf > nix.conf.new ; rm nix.conf ; mv nix.conf.new nix.conf ; vi nix.conf
<clever> yeah, that would still cause issues
<clever> ah
<clever> samueldr: yeah, that does sound strange
<clever> or dont install cabal
<clever> jtojnar: nix-shell --pure
<clever> id need more context to know whats going on
<clever> and /etc/nix/nix.conf agrees?
<clever> samueldr: do you have sandboxing enabled on the local machine?
<clever> dhess: trusted users are allowed to import unsigned things, which is a common when its being used as a build slave

2017-12-19

<clever> if you have an error from a recent setup, i can help you debug it
<clever> theres not much debug for build slaves
<clever> yeah
<clever> yeah, the user that nix-daemon runs as has to trust the host
<clever> happens any time you dont have a build slave for a given arch
<clever> dhess: thats a standard nix error
<clever> dhess: how did you configure your linux build slave?
<clever> dhess: you need to have linux build slaves available for building the nixos machines
<clever> pass config = { allowUnfree = true; }; to it
<clever> and that doesnt affect the nixpkgs you import manually
<clever> nixpkgs.config = { allowUnfree = true; };
<clever> fresheyeball: nixpkgs.config = { packageOverrides = pkgs: { teamviewer = something; }; }; i believe
<clever> fresheyeball: use a packageOverride to change the teamviewer package, which should affect what services.teamviewer.enable uses
<clever> catern: try tab-completing builtins.e under nix-repl
<clever> yeah, it should have been broken for months, cant see why it worked until just recently
<clever> to git blame!
<clever> which fails the check
<clever> oh, the user is set in the common options, so it was root@localhost
<clever> still not clear why i saw it break on that recent system
<clever> ah, if the slave is literally just "localhost" it special-cases it to not break
<clever> most of them build on seperate machines, i found one yesterday that was unable to build anything, because hydra grabbed a lock on $x, then ssh;d into itself to build $x, which waited on the lock, forever
<clever> dhess: ive seen deadlock issues with hydra builds on localhost

2017-12-18

<clever> 0.0.0.0:2222 makes it listen on any interface
<clever> the ip&port the server listens on, then the ip&port the server connects to
<clever> 00~[-R [bind_address:]port:host:hostport]01~
<clever> yes, check the man page
<clever> infinisil: also, tmate does the same thing with much much less fuss
<clever> infinisil: ssh defaults to listening on localhost when it does that
<clever> infinisil: Connection refused implies that the firewall allowed you in, but nothing is listening
<clever> and the // on lines 20 and 31, can overwrite that with a new value
<clever> dhess: this says how many shares the builds get within that jobset
<clever> which is why a lot of my projects have duplicate jobsets like this
<clever> now you have an early-warning radar, of when unstable breaks stuff on you
<clever> and then you can spawn 2 jobsets, one with nixpkgs absent (it obeys the fixed version), and one with it present (it builds from unstable)
<clever> { nixpkgs ? (import ./lib.nix).fetchNixpkgs, other, stuff }:
<clever> your release.nix could also do this
<clever> yep
<clever> then you can just entirely omit nixpkgs in the inputs for the jobsets
<clever> and nothing else
<clever> yeah, that 17.03 is only used for one thing, to write the json to a file
<clever> and line 42 then writes that to a file in the store and passes it back to hydra
<clever> then i just use "regular old nix" to parse the json in pulls, manipulate all the data, and generate a set of jobs
<clever> 13 fetches the latest nixpkgs 17.03, and line 4 of that default.nix imports it
<clever> line 15 fetches all pull requests on my github, and feeds them into line 1 here: https://github.com/cleverca22/hydra-configs/blob/master/toxvpn/default.nix#L1
<clever> the other inputs are passed to default.nix as arguments, and also put into $NIX_PATH
<clever> and every attribute in that file becomes a job in the jobset
<clever> dhess: nixexprinput=configs, and nixexprpath=toxvpn/default.nix, so it will fetch the configs defined on line 14, then eval hydra-configs/toxvpn/default.nix
<clever> dhess: nix will attempt to build nixexprpath, which is found in the input named by nixexprinput
<clever> and you can use whatever whacky (but pure!) programming you want to generate that list of jobsets
<clever> that json file then contains a object of objects similar to the original spec.json, which configure the remaining jobsets on the project
<clever> hydra will then build whatever it specified, and it expects the jobset to contain a single job called jobsets, which must produce a json file
<clever> dhess: so .jobsets is auto-created, and its config is locked to match the spec.json file
<clever> dhess: the way it works, is that the spec file defines all of the config for a jobset called .jobsets
<clever> dhess: just create a project and input that url
<clever> dhess: yeah, and then the spec file does the rest of the project config
<clever> if you set hydra up like this, it will download that spec.json, and then configure everything else based on it
<clever> makefu: i think the only documentation i found, was a comment on a random commit in the hydra github
<clever> if you point hydra to a file like this, it will auto-configure the entire project
<clever> dhess, makefu: the declarative hydra jobsets handle some of that
<clever> makefu, dhess: you can also bounce questions off me, ive setup ~5 hydras, and help maintain a 6th
<clever> cmiles74: it should just run things like "gpg" or ${gpg}/bin/gpg
<clever> cmiles74: first thing to try is to run sed over it to fix the paths up
<clever> try peeking at another process
<clever> it might be that something modified the env
<clever> its a null between every k/v pair
<clever> judson: try runinng a text editor directly on that file, rather then using strings
<clever> judson: the issue, is that the file has null bytes in it, try opening it in a text editor that supports nulls
<clever> catern: also, i prefer always building with the nix sandbox on, so all impure hacks are blocked
<clever> catern: the more impurity you add, the harder it is for nix to rebuild at the right time, and then things go horribly wrong and things just dont rebuild
<clever> samueldr: if you run strings on /proc/PID/environ, you can peek at the env variables for any process
<clever> catern: the issue, is that all of the mechanics for detecting when to rebuild stuff, is based on hashing things and putting them into the store
<clever> catern: not really, it would be better to just restrict who has access to that nix store
<clever> fendor: you need let unstable = import <unstable> { config = { allowUnfree = true; }; }; in
<clever> fendor: that isnt the same as what you gave in irc
<clever> fendor: can you gist the nix file that causes the error?
<clever> fendor: at what path?
<clever> fendor: what does nix-instantiate --find-file nixos-unstable say?
<clever> but sometimes a special flag doesnt have one
<clever> i prefer using the nixos options
<clever> greglearns: nixos sets it up for you, but your protections are blocking it
<clever> greglearns: the /.well-known/ directory cant be protected
<clever> greglearns: does the dns for v1.website.com point to the machine managed by nixos?
<clever> orivej: try "ncdu -x /"

2017-12-17

<clever> bkchr: wine is already packaged in nixpkgs, so that would be simpler to use
<clever> bkchr: oh, and it expects patchelf in $PATH, nix-shell -p patchelf first
<clever> bkchr: that bash script will then just patch whatever its pointed at
<clever> bkchr: in the default state, just run nix-build on it to generate a bash script
<clever> yeah
<clever> bkchr: by setting system to the 32bit tag, it automaticaly gives 32bit everything
<clever> simple answer, reboot
<clever> but there is no simple way to see those
<clever> pbogdan: any running program, any path in env vars, and any path in a working directory, is also "in use" and rooted
<clever> pbogdan: i meant, in ram
<clever> pbogdan: it can also be invisibly rooted by being in use by things
<clever> pbogdan: nix-store --query --roots
<clever> ottidmes: which configuration.nix are you editing?
<clever> and that doesnt include the parallel -> serial conversion
<clever> about 3 years ago, i wrote some verilog by hand (prior to discovering nix and functional programming), just the state machine for driving an ethernet module to transmit a packet is 500 lines of verilog
<clever> and how insane is it that i can debug haskell like that?, or that ghci cant do something so simple? lol
<clever> yeah
<clever> thoughtpolice: i just had an idea on how to debug pure haskell functions, turn them into verilog, then inspect the state flow in gtkwave, lol
<clever> verilog.out 61,232 x /nix/store/1wiwbvvp44i1djaxcjsvzxnpy14dbx8i-iverilog-2016.05.21/bin/iverilog
<clever> yeah, iverilog i think
<clever> maybe i was thinking of verilog
<clever> thoughtpolice: what was that program to simulate vhdl, that went along with gtkwave?
<clever> ertes: so you would do boot.initrd.luks.devices.a and boot.initrd.luks.devices.b
<clever> ertes: after that, i believe its down to the order of the keys in mapAttrsToList
<clever> ertes: the first major level of ordering, is the prelvm and postlvm stuff
<clever> thats the simplest way to bypass the signature checks
<clever> andi-: you need to add the build user as a trusted user
<clever> neat
<clever> andi-: can it do more?
<clever> andi-: nice
<clever> sphalerite: double-check to see what the configure script has
<clever> sudoreboot[m]: the stateVersion has no control on what channel it uses
<clever> sphalerite: neon support
<clever> sphalerite: there should be --configure flags to turn that off

2017-12-16

<clever> pull is fine
<clever> push wont like pushing ti working directories
<clever> but maybe something else has changed in unstable, i havent given it root yet
<clever> that should happen by default
<clever> can you gist the remote "ps -eH x"
<clever> check network activity and "ls -ltrha /nix/store" on the remote end, there should be hidden files
<clever> there will be a long delay of nothing at the start, as it copies deps
<clever> sphalerite: the only feedback i know if, is that the normal stdout stream continues to work
<clever> +1
<clever> and this even older variant
<clever> coming up on 2 years old
<clever> and i left that patch laying around far far too long
<clever> i dont remember how the new Setting stuff worked
<clever> that would explain why the problem felt familiar, lol
<clever> heh
<clever> does that help?
<clever> sphalerite: oh, one min
<clever> but no signature
<clever> export includes the list of deps for each path, and the hash of the nar, along with its storepath
<clever> ah
<clever> export/import follow
<clever> dump/restore ^^
<clever> so you have to -qR and pass the closure to export yourself
<clever> but not the closure
<clever> import/export include the full storepath of each nar
<clever> yep
<clever> it doesnt even have the name of the root node
<clever> yeah, dump is basically tar
<clever> dump and restore are much simpler, and cant
<clever> not sure
<clever> those manage whole closures
<clever> sphalerite: there is import and export
<clever> ah, then the compression would have to be changed within nix
<clever> ah, is it a new `nix copy` that generates a directory of .nar.xz's ?
<clever> what server at the other end?
<clever> sphalerite: how is the the cache being served?
<clever> so nix-daemon needs to just send the right flag
<clever> yeah, but the remote end does support it
<clever> i have chained by mistake
<clever> sphalerite: i know nix-copy-closure can make the remote system use a binary cache, but i dont know if hydra/nix-daemon can trigger that automatically
<clever> jmc_fr: the hostname.nix can then have something like ./core.nix added to imports, to share config between several systems
<clever> each host has its own unique file that is added to imports, and all can share nixcfg
<clever> jmc_fr: then configuration.nix just contains the bare minimum to boot, and imports = [ ./nixcfg/hostname.nix ];
<clever> jmc_fr: i tend to put a git repo at /etc/nixos/nixcfg/
<clever> and the SPL that comes with u-boot is concated to u-boot itself, and expects u-boot to follow
<clever> yeah, the allwinner line loads an SPL (secondary program loader) from a given offset on many media
<clever> in both cases, the dram is offline, and that first stage goes into the L2 cache of the cpu
<clever> yeah
<clever> jmc_fr: there should be vbox utils in /run/current-system/sw/bin
<clever> jmc_fr: are the commands for sharing folders in $PATH/
<clever> jmc_fr: that option will install and configure it all for you
<clever> jmc_fr: 00~https://nixos.org/nixos/options.html#virtualbox.guest.enable
<clever> i often say, docs can lie, the source cant
<clever> the map on 160 then fetches the a and b from args or config._module.args
<clever> and the attrNames turns it into [ "a" "b" ]
<clever> so { a, b, ... }: returns a { a=false; b=false; }
<clever> line 158 queries the function to get its arguments
<clever> so passing a set doesnt fail with an error, and just ignores the args
<clever> applyIfFunction just decides if its a function or not, and calls it with the args if it can
<clever> andromeda-galaxy: deep within the bowels of the module framework
<clever> andromeda-galaxy: i think thats the foo in systemd.services.foo
<clever> so it has the same size as list1 and list2
<clever> i'm guessing that would be listn, with the elems set to null
<clever> i also just noticed, there is no special type for lists of size 0
<clever> and will include cmake in the sandbox
<clever> so just doing buildPhase = "${cmake}/bin/cmake"; will make sure cmake is built before your thing
<clever> and when you call the builtins.derivation function with a string, the derivation it creates will auto-magically depend on the derivations the strings refered to
<clever> every string in nix, has a list of derivations the string refers to
<clever> oh, and line 125, strings are special
<clever> while listn stores a pointer to the list
<clever> list1 and list2 directly store the first 1 (or 2) items into the union
<clever> for lists of length 1, 2, or n
<clever> so, internally, it has 3 types for lists
<clever> because of that union, all values are 2 pointers long, plus a type tag
<clever> every value in nix is stored as a union of many things, along with an enum for its type
<clever> andromeda-galaxy: oh, and there are some other fun tricks in nix involving lists
<clever> and then restores things back to thunk type as it goes up the call chain
<clever> so it throws a c++ level exception
<clever> if it encounters a blackhole while recursively doing that, it knows it has circled around and will cause infinite recursion
<clever> and after it returns, the type it changed to a base type (int, string, set, list, bool)
<clever> if you attempt to read it, the type will be temporarily changed to black hole, then the function ran
<clever> all expressions and function calls are initialy of type thunk, which contains a function pointer and argument pointer
<clever> ive also read the source behind how nix handles lazyness
<clever> and other top-level modules, are being passed their own return value
<clever> its being passed the config that it defines the options for
<clever> thats the fun thing with nix and lazyness
<clever> the systemd module that is
<clever> but the author of systemd choose to not do that
<clever> unitConfig could define both options and config at the same time
<clever> with import ./systemd-unit-options.nix { inherit config lib; };
<clever> unit*
<clever> in the case of unixConfig, the options like .description and unitConfig are being defined elsewhere
<clever> and then it works basically the same way as top level modules
<clever> id say you need to pass a function any time you want to set config based on other config
<clever> and then unitConfig can map that to systemd.services.foo.unitConfig.Description
<clever> so if i set systemd.services.foo.description, it will pass { description = "something"; } to unitConfig
<clever> the module system will pass unitConfig a subset of the options
<clever> so all options defined under unitConfig, can be set on mounts, paths, timers, sockets, services, and targets
<clever> andromeda-galaxy: i think it just merges the options defined in each item in the list
<clever> :S
<clever> try making a diff and adding it to patches?
<clever> but it is possible those sed commands can fail silently
<clever> nothing immediately stands out as wrong
<clever> neonfuz: can you gist the nix expression?
<clever> neonfuz: what path is it not finding during nix-build?
<clever> neonfuz: --pure only wipes the environment, but it doesnt block access to hard-coded paths

2017-12-15

<clever> mitchty: nope
<clever> i didnt think nix-shell was able to fail like that with --run
<clever> yep
<clever> to tell it to just ignore config.nix
<clever> you can also import <nixpkgs> { config = {}; }
<clever> then you told it to allow such failures, and the safety net failed, to stop you from doing exactly that
<clever> and 2048 is linux only, so it failed
<clever> 2048 was first, because numbers before letters
<clever> yeah, all of nixpkgs