<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>
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>
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>
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>
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>
_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>
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>
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>
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>
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>
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