2017-03-16

<clever> hyper_ch: exactly the same value your setting it to
<clever> hyper_ch: line 42, if you set isNormalUser=true;, home is set for you, with a sane value
<clever> pallav: builtins.readFile (pkgs.runCommand "foo" { buildInputs = []; } "echo stuff > $out");
<clever> pallav: should be able to call readFile on the result of runCommand
<clever> pallav: there is also a builtin to read a directory listing
<clever> neeasade: and for extra fun, --list gives them in the other order
<clever> neeasade: check nix-channel --help
<clever> nixos-rebuild uses the channed called "nixos" by default
<clever> neeasade: do nix-channel --list
<clever> neeasade: nixpkgs-unstable only confirms that vim + emacs work on linux + darwin
<clever> neeasade: nixos-unstable waits for testing to ensure it wont brick a nixos machine

2017-03-15

<clever> copumpkin: i believe so, havent gotten arround to trying it
<clever> copumpkin: overrideDerivation happens after mkDerivation has mutated things, and probably after it stripped passthru
<clever> copumpkin: i think you want overrideAttrs
<clever> hydra-create-user admin --password hunter2 --role admin
<clever> export HYDRA_DBI="dbi:Pg:dbname=hydra;user=hydra;"
<clever> joko: i had to run something as the hydra user, to create the account
<clever> justanotheruser: so you can add more libraries on line 5, then run nix-build to get a bash script, then you can use the bash script to patch anything
<clever> justanotheruser: that will create a bash script that does the patchelf for you
<clever> justanotheruser: https://gist.github.com/cleverca22/8cae5bc9c02c12099a3bf5e20e75161f something else ive written before
<clever> justanotheruser: and this forces skype to load in 32bit only mode
<clever> skype = callPackage_i686 ../applications/networking/instant-messengers/skype { };
<clever> justanotheruser: line 44 just finds the paths for you
<clever> justanotheruser: and its usualy easyer to write a package to do it for you
<clever> justanotheruser: just patchelf against the paths for the 32bit libs
<clever> justanotheruser: you dont need to install the libs
<clever> though with nixos, you can just stick that in the initrd and shortcut your way around it
<clever> simpson: yeah, its configured from a script that runs on bootup
<clever> then it could be open for 30 sec or more
<clever> simpson: it may need to wait for the whole userland to boot, and run an init script
<clever> simpson: once linux boots, it begins controlling the switch chip over a control bus, and can isolate the ports from eachother
<clever> simpson: so the wan port has full access to your lan, until linux boots
<clever> simpson: main problem ive discovered with the above router, is that the switch defaults to routing everything everywhere
<clever> justanotheruser: you need to patchelf things
<clever> justanotheruser: installing 32bit libs like that wont fix linker errors in random ELF files
<clever> justanotheruser: oops, its pkgsi686Linux
<clever> simpson: the BPI-R1 above, is basicaly a 6 port switch, with the 6th port directly wired to the A20 processor
<clever> simpson: oh, it appears to be the same family of processor, could share code then
<clever> simpson: ive got a even more weird arm board on the way that i want to target
<clever> simpson: yay! :D
<clever> justanotheruser: you need to use the pkgs_i686 attribute within nixpkgs, to get 32bit builds, and you shouldnt nix-env -i 32bit stuff like that
<clever> simpson: ahh yeah that project
<clever> simpson: 3.4 doesnt sound that old
<clever> justanotheruser: do you have a nix expression for the package?

2017-03-14

<clever> sziszi: it tried to chmod -1, which made it 777, and setuid
<clever> sziszi: there was a systemd bug worse then 777
<clever> any user can now do anything to that device, and possibly other usb devices
<clever> yeah
<clever> there was a udev issue a while ago, that prevented steam from being able to read the usb dev nodes in /dev/bus/usb/
<clever> i just opened the source, identified the schema changes, and manualy undid them
<clever> i had a similiar problem in december, when i installed nix master onto a laptop that was still running a 2015 build of nix
<clever> dhess: if nix-daemon is in use, then remote-build stuff has to be setup in the env of nix-daemon, not nix-build
<clever> thats something else then
<clever> ah
<clever> dhess: if it cant find any remote build slaves configured, nixops will automaticaly use the target machine as a slave, when the host isnt linux
<clever> dhess: nixops does some weird things with remote-builder
<clever> null_: is it added to all-packages.nix or config.nix?
<clever> freusque: nix-repl is also good for learning, you can just type in fragments of nix and build then with :b
<clever> sounds like apples version of NFS
<clever> ah
<clever> havent heard of netatalk
<clever> devoid: nfs supports uid's and chmod, so it its best when both ends are unix like
<clever> devoid: i would try nfs first, then smb
<clever> and its starting to get late here, so i'm off to bed, goodnight :)
<clever> phI||Ip: you can then take the hash from the individual paths, and query cache.nixos.org/<hash>.narinfo to check the cache, and get more data
<clever> phI||Ip: this spits out the storepath for every single build in http://hydra.nixos.org/eval/1341311
<clever> curl http://hydra.nixos.org/eval/1341311/store-paths -H 'Accept: application/json'
<clever> nh2: need to use mkForce on serviceConfig, and then you loose the path to nginx.conf
<clever> nh2: the entire serviceConfig set is considered a single option, so you cant use mkForce on after
<clever> it doesnt now...
<clever> it did...
<clever> wait
<clever> gchristensen: it does for me
<clever> phI||Ip: /etc/nix/nix.conf
<clever> there is an index somewhere in hydra, that is used to generate the command-not-found db
<clever> yeah
<clever> which isnt ideal
<clever> yeah
<clever> even if its a binary identical copy of the original
<clever> but in both cases, the cache.nixos.org-1 signature is lost
<clever> phI||Ip: nix-push will bulk package&sign a store and create a directory you can serve with a dumb static-file http server
<clever> phI||Ip: nix-serve will dynamicaly package things directly from /nix/store on-demand, and sign them with a private key you create
<clever> nix-serve*
<clever> phI||Ip: that only happens if your using nix-cache or nix-push
<clever> yeah, because every path is immutable, the tty can just be infinity
<clever> phI||Ip: and i believe nginx will obey the cache-control headers, and can serve a request up without re-checking the source, within configured time windows
<clever> it is passing traffic, but it doesnt appear to be caching yet
<clever> nh2, phI||Ip: https://gist.github.com/anonymous/ae2715775f0e24bce59ca4a83cf3fac4 is what i have so far
<clever> nh2: if i dont ssl the upstream side, it can proxy-pass, testing the cache now
<clever> nh2: nixos is a bit weird with ssl
<clever> nh2: looks like nginx lacks a CA root by default
<clever> nginx[9610]: 2017/03/14 00:55:55 [error] 9933#0: *23 SSL_do_handshake() failed (SSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure) while SSL handshaking to upstream
<clever> nh2: let me throw something together
<clever> nh2: yeah, that would be great
<clever> chattered: that should be working, i cant see any obvious reason why it wouldnt
<clever> nh2: ah, didnt think nginx had that mode, https://www.nginx.com/blog/nginx-caching-guide/
<clever> chattered: can you gist your nix expression and the full error?
<clever> chattered: mesa contains include/GL/gl.h
<clever> chattered: for GL, you should just add mesa to the buildInputs
<clever> chattered: the way it uses makefiles is very weird, i havent been able to get darling to compile
<clever> so the users have to trust that the new pairs
<clever> nh2, phI||Ip: the other main options are nix-push and nix-serve, but those re-sign it under your own binary cache keys
<clever> sp they connect to https://cache.example.com with cache.example.com's cert, which decrypts, then re-encrypts under the cache.nixos.org cert
<clever> nh2: and for extra points, you can always put your own ssl on that cache, to preserve the privacy of the users
<clever> nh2: yep
<clever> benley: yep
<clever> brb
<clever> nh2: so it will try to download that nar from the same machine
<clever> nh2: its relative to the narinfo file
<clever> nh2: oh wait, its called URL:
<clever> nh2: at which point, you might as well just cache the narinfo's
<clever> nh2: so there is no easy way to tell it to get the narinfo from one place and the nar from another, without having to intercept the narinfo requests
<clever> nh2: the issue is that the nar: field in the narinfo says where to get the .nar from
<clever> _deepfire: overrideAttrs changes the attrset passed to mkDerivation
<clever> _deepfire: .override can change the arguments to a file on line 1 of its default.nix
<clever> _deepfire: name must be overrideAttrs, but libsOnly and kernel must be override
<clever> nh2: you would need to cache the pair of files from the real cache, and the signature just prooves that you havent modified it any
<clever> _deepfire: you must use .override to set kernel = null;
<clever> _deepfire: your still not using .override
<clever> nh2: so you need to cache both the narinfo and nar, to maintain the signature
<clever> nh2: thats one minor issue with binary caches, nix looses the signature when installing
<clever> to prime the cache
<clever> nh2: about all i can think of there is to just nix-build the paths of interest, with that cache in your list
<clever> nh2: i was thinking of building it lazily like cloudflare, so the cache only gains files upon a miss
<clever> nh2: so if bare http is used, all an attacker can do is know what your downloading
<clever> nh2: every .nar is signed by a key on the hydra server, and the public half is in your nix.conf
<clever> nh2: i'll toss you a msg when i get around to working on that idea

2017-03-13

<clever> gchristensen: a bit slow from this server: https://gist.github.com/cleverca22/6d6e74f97a313628f2830128655c55f1
<clever> gchristensen: my first request from OVH missed CF and took a while, forgot to time it, now its hitting the cache, and responds between 0.1 and 1.0sec
<clever> _deepfire: and the /run/opengl-drivers is to let it be swapped out at runtime, so you dont have to rebuild everything using xorg
<clever> _deepfire: the biggest problem, is that the libGL used by an xorg client has to be compatible with the libGL inside the xorg server
<clever> _deepfire: ah
<clever> yep
<clever> _deepfire: where is the actual point of use?
<clever> _deepfire: it looks like the main use is on line 19, which is in foo.nix?
<clever> gchristensen: and if you use https://cache.nixos.org/ squid cant do anything, ssl protects the link
<clever> gchristensen: squid can expire things, and it generaly doesnt cache large objects without extra config
<clever> nh2: so you can set your nixops cluster to all use the cache cache, and then it only hits cloudfront once for each derivation
<clever> nh2: ive was thinking about how to make a binary cache cache
<clever> _deepfire: and also, .overrideDerivation and .override work at very different layers
<clever> the linuxPackages stuff may make other changes to it
<clever> _deepfire: i think you want this, and use that directly, dont insert it back into linuxPackages
<clever> linuxPackages.nvidia_x11.override { libsOnly = true; kernel = null; }
<clever> _deepfire: oh, yeah, its not in the root
<clever> _deepfire: it might just be called nvidia
<clever> _deepfire: libsOnly is part of .override
<clever> _deepfire: oh, and overrideDerivation is the wrong thing to use, that wont set the right libsOnly
<clever> _deepfire: i dont think you need to play with linuxPackages at all, you can just directly use an override from pkgs.nvidia_x11
<clever> _deepfire: oh, and what file are you putting the override in?
<clever> _deepfire: some places in nixos apply their own overrides ontop of yours: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/hardware/video/nvidia.nix#L28
<clever> _deepfire: xorg has to link against a copy built with libsOnly = true; kernel = null;, while the kernel needs a copy with those values flipped
<clever> the build just runs as your own user
<clever> if sandboxes and the daemon arent enabled, its much simpler
<clever> ah
<clever> simpson: at least with the socat trick, you can kill socat and then builds can no longer access the agent
<clever> simpson: and also, every build you run will be able to read the key
<clever> simpson: you could also put the private keys in /tmp and make them readable by the nixbld group, then ssh_config needs to be set to read an unsafe key file
<clever> simpson: and because of the build slaves, hydra cant use the hack from the gist, /tmp/hax would have to be setup on every box, each with its own key&agent
<clever> simpson: but every private repo has to be a seperate input in hydra, and that could get messy for a large project
<clever> simpson: hydra fetches the build inputs by just running nix-prefetch-git as the "hydra" user, so you can just sudo -u hydra -i ; ssh-keygen
<clever> simpson: hydra is easyer, heh
<clever> simpson: the idea is to add a flag to nix-build, that works the same as "ssh -A" and allows the builder to use an agent near the nix-build process
<clever> simpson: with nix-build or hydra?
<clever> eacameron: this links to the tests for every channel, and says how old they are
<clever> but firefox looks iffy
<clever> i dont see anything failing in the recent evals, just queued
<clever> MoreTea: a few months ago, nixpkgs-unstable had a fatal flaw in its grub.conf logic, broke the ability to boot, including rollbacks
<clever> MoreTea: one issue i have seen people do, is installing nixos from nixpkgs-unstable
<clever> MoreTea: i always installed from nixos-unstable, and often upgrade it, never had any major issues
<clever> Baughn: :D
<clever> Baughn: and only the --restore has to be done on the target
<clever> Baughn: this shows how to download any storepath to the current directory, directly from the binary cache
<clever> [clever@amd-nixos:/tmp/fooo]$ curl cache.nixos.org/nar/0b1c57kbqjl78yh5wvna3lgfzldjk12s5a5kkyq49qd07jgy4p0p.nar.xz | unxz | nix-store --restore bdjyhh70npndlq3rzmggh4f2dzdsj4xy-hello-2.10
<clever> if you can find a working xz, curl, and nix-store, you can manualy access the binary cache
<clever> so once you find a good generation, you can use it for others
<clever> everything within a given system-42-link should use the same ld.so
<clever> you can manualy symlink it to one of the /nix/var/nix/profiles/system*/sw/bin/sh files
<clever> try a different nix-store?
<clever> echo /nix/var/nix/profiles/system*/sw/bin/file
<clever> Baughn: you can download directly from the binary cache, if you paste in full storepaths
<clever> Baughn: you would need to find a functional nix, and then run things like "nix-store -r /nix/store/3qag0gwlar4rsh786ff25f4zdw6vqb7d-perl-5.22.2"
<clever> Baughn: i do have an example i made recently, on how to get hydra in 16.09
<clever> nixos-install is basicaly just a bash script that runs nixos-rebuild under a chroot
<clever> Baughn: if you just re-mount the fs, set the right channel, and nixos-install, it will repair every missing thing in the store, and rebuild the os from the existing config
<clever> yeah, similiar to what i saod to benley
<clever> thats fairly different from valid outputs that just arent rooted
<clever> Baughn: the database claimed those things didnt belong there and where invalid, so it got rid of them
<clever> Baughn: so it deleted half the store
<clever> Baughn: it sounds like you didnt properly restore the nix database, so it considered half of your store invalid
<clever> benley: just make sure the new uuid for the new /boot is updated in the configuration.nix/hardware-configuration.nix
<clever> benley: and if things do go wrong, you can just correct that from the install iso
<clever> benley: i'm guessing you can just format /boot again with luks over it, mount it to /boot, and then nixos-rebuild boot
<clever> until boot works on one of them
<clever> Baughn: try an older generation, look at the contents of /nix/var/nix/profiles and work your way down from the highest numbered system
<clever> if you run "switch-to-configuration boot" in one of those, it will flag that profile as the default for bootup
<clever> and also, the system-1234-link symlinks in profiles
<clever> next thing then, /nix/var/nix/profiles/system/bin/switch-to-configuration
<clever> i have plans on how to fix that, but havent gotten anything usable yet
<clever> oh
<clever> that would usualy fix it
<clever> simplest thing i can think of is to just try rebooting and picking an older generation from grub
<clever> can you pastebin the last dozen or so lines of the history command?
<clever> or nix-store --delete?
<clever> Baughn: did you run any garbage collection?
<clever> Baughn: $PATH is bork, so you must use the absolute path to the ls binary
<clever> Baughn: /nix/var/nix/profiles/system/sw/bin/ls -l /run/current-system
<clever> Baughn: oh, and also, what does "ls -l /run/current-system" sat?
<clever> Baughn: /nix/var/nix/profiles/system/sw/bin/ is where you will find all of the systemPackages
<clever> Baughn: that shouldnt have touched /run stuff
<clever> Baughn: what did you do?
<clever> viric: i'm not currently updating a channel, but i am following nixos-unstable-small, so if you just use that channel, you have a decent chance of hitting my cache

2017-03-12

<clever> for a basic template, its just a pile of string concats
<clever> and internaly, the jade engine just turns your template into a javascript function
<clever> apostolis: jade is specialized around generating html, and can run JS on input data to fill in fields or repeat sections of the table
<clever> weird, the jade-land site now redirects to pugjs
<clever> how did that url turn to pug? lol
<clever> wait
<clever> the general syntax also reminds me of jade
<clever> ive had to write some pascal code generators in c++ before
<clever> ah neat
<clever> apostolis: and the writeText function returns the path in the store
<clever> apostolis: an example i pasted about 5 hours ago, this turns the attribute set inside config_set into a json string, then writes it out to the /nix/store as /nix/store/HASH-config.json
<clever> CONFIG_FILE = pkgs.writeText "config.json" (builtins.toJSON config_set);
<clever> apostolis: that will turn a nix attribute set into a string with json
<clever> the above derivation will run foo.py on data.txt, and produce a single output file
<clever> it would look something like pkgs.runCommand "name" { buildInputs = [ python ]; } "python ${./foo.py} ${./data.txt} > $out"; as a very basic example
<clever> apostolis: but you might be better off just using pkgs.runCommand
<clever> apostolis: and then python would be the builder
<clever> apostolis: if you manualy made a derivation like this, you can set the builder to the python binary, and args to be a path to a python script
<clever> apostolis: this is directly calling the derivation function in nix, and it bypasses the entire stdenv.mkDerivation system
<clever> apostolis: if you dont care about things like buildInputs being handled for you, then you could, one min
<clever> ah
<clever> apostolis: what are you wanting to do?
<clever> you dont even get buildInputs -> $PATH if you bypass the real builder
<clever> sheenobu: yeah
<clever> vovapi: you should be able to change it to with python27Packages; [ six ];
<clever> but they appear to have omited that detail
<clever> vovapi: in that guide, self is an instance of pythonPackages
<clever> vovapi: you are trying to reference this package, which is called self
<clever> description = "A prototype-based dynamic object-oriented programming language, environment, and virtual machine";
<clever> vovapi: why are you doing "with self;" on line 13?
<clever> vovapi: i think its because you have another with elsewhere, and its picking the wrong self
<clever> but it lacks a libc, so its only of use for building kernels
<clever> in theory, it would let you make an arm cross compiler, even on darwin
<clever> smw_: that will give you a directory containing an arm cross-compiler
<clever> but for this kind of debug, it may be faster to manualy cross-compile the kernel on an x86 machine
<clever> if built with nix, yes
<clever> when the kernel is built
<clever> smw_: there is also some earlyprintk stuff, that forces a serial port on much much sooner
<clever> smw_: ah
<clever> smw_: could be kernel config, let me look for some debug options
<clever> they probably had binary cache in mind
<clever> with the split output stuff, you can now get the same effect from boost.dev, except it still has to build the entire thing
<clever> just compare the derivation names within your build and hydra
<clever> boost boost-build boost155 boost159 boost160 boost162 boost163 boost_process
<clever> what is the link to that hydra?
<clever> viric: i think i needed 1gig of swap file to make boost pass, but even with the swap file deleted, i dont have enough free space to finish an sdImage build
<clever> viric: moar swap!
<clever> viric: not currently
<clever> 92edcb7ebbf5b4b324288ec62bebbc58a3f96ef6 is the first bad commit
<clever> ah
<clever> i should try that...
<clever> it should be possible to make a single nix file that either passes or fails, then just nix-instantiate and git bisect
<clever> somebody that recently redid stuff near top-level/impure.nix or top-level/default.nix
<clever> the problem is that pkgs.platforms depends on nixpkgs.config, which depends on pkgs.platforms
<clever> it needs to re-import a new copy of <nixpkgs>
<clever> viric: you will need the same fix there
<clever> viric: turns out the user had $NIXOS_CONFIG set in one of them
<clever> viric: i had a similar problem a week ago where nixos-rebuild was outright ignoring config flags outside of tmux, but obeyed them in tmux
<clever> viric: NIXPKGS_CONFIG might be he problem, try unsetting that and using ~/.nixpkgs/config.nix
<clever> viric: what does "env | grep NIX" output?
<clever> import <nixpkgs> { config = {}; }; this should force the 2nd nixpkgs to have no config.nix file
<clever> wait nvm
<clever> viric: because you are doing it in config.nix, not configuration.nix
<clever> viric: oh, i think i see the problem
<clever> viric: yeah, the config.nix and the traceback from --show-trace