<clever>
reallymemorable: thats just normal sudo rules, you must know your own pw, or set one with something like `passwd reallymemorable`, as root
<clever>
and now you can start the socat as root, pointing to the unix socket the agent is running on
<clever>
and the agent will never give the key out, only sign things for you
<clever>
nixbld talks to the agent, which has a copy of the key loaded in memory
<clever>
thats the whole point of the agent
<clever>
thats a warning that anybody in your group can read your ssh key, you may want it to be chmod 600
<clever>
just copy/paste those back into the terminal
<clever>
reallymemorable: when you run ssh-agent, it will print a few lines out
<clever>
reallymemorable: it sounds like SSH_AUTH_SOCK still isnt set right, so the ssh-add is failing
<clever>
and ssh-agent has an exception to allow root, so `sudo ssh` can still use the agent
<clever>
so you have to setup an socat to act as a proxy, which is connecting from root
<clever>
reallymemorable: the main uid issue, is that when a member of nixbld connects to $SSH_AUTH_SOCK, ssh-agent rejects them hard, for security reasons
<clever>
reallymemorable: not really that different, just make sure the $SSH_AUTH_SOCK is pointing to the socket for the users ssh-agent
<clever>
reallymemorable: as a normal user, except for the socat, which the example shows being used with sudo
<clever>
reallymemorable: the commands in that gist will allow fetchgitPrivate to talk to ssh-agent
<clever>
Aleksejs: looks like a problem inside pycurl, you could maybe disable printer support temporarily (since config-printer depends on pycurl)
<clever>
you didnt correctly eval the output of ssh-agent
<clever>
reallymemorable: running ssh-add, will add ~/.ssh/id_rsa to the currently running agent
<clever>
reallymemorable: you need to run ssh-agent, and then export the vars it prints, then also run ssh-add
<clever>
srhb: lddtree isnt like `find .`, but rather, it will show the dep-tree of the DT_NEEDED's
<clever>
dcol: lddtree should reveal that
<clever>
dcol: if it is needed by another lib, and not the executable, the it uses that libs rpath
<clever>
dcol: when one of those libraries tries to load another, it uses its own rpath, not the rpath on the executable
<clever>
dcol: does the package have its own libraries?
<clever>
srhb: thats practically what tgt-admin was, it would diff the config against the daemon state, and then run modify commands to re-sync it
<clever>
because its actually managing "services" within the tgtd proc
<clever>
and 25-38 is also a one-shot, with an execstop
<clever>
srhb: how would i get the service on lines 25-38, to restart any time the service on 59 restarts?
<clever>
srhb: but, you need to restart those target units, any time tgtd restarts, and other fun problems
<clever>
srhb: i decided to skip that perl script, and make a systemd unit for every single target, and just call tgtadm directly, to add/remove things from tgtd, rather then re-sync the daemon to the cfg
<clever>
srhb: then you have tgt-admin, a perl script, that parses the config file, and calls tgtadm, to configure the daemon correctly
<clever>
srhb: then you have tgtadm, an ELF binary, that will RPC into tgtd, and add/remove things
<clever>
srhb: behind the scenes, there is a tgtd daemon, which runs the iscsi target, but it doesnt support its own config files!
<clever>
NemesisD: runAsRoot has performance costs, due to needing to fire up a full qemu VM, i try to do things at runtime to avoid that
<clever>
benwaffle[m]: but if your already using substituteInPlace, it would be simpler to --replace "@shell@" "$shell"
<clever>
benwaffle[m]: which will replace @shell@ with the value of $shell for you
<clever>
benwaffle[m]: its usually handled by substituteAll
<clever>
benwaffle[m]: replace @shell@ with $shell
<clever>
benwaffle[m]: yeah, thats one solution
<clever>
reallymemorable: using build slaves makes fetchgitPrivate a lot more complicated to use, which is why builtins.fetchGit is the better replacement
<clever>
reallymemorable: it is a function within nixpkgs, that is used to download focus-phonepush-worker
<clever>
reallymemorable: something that ghci-backend is doing involves calling fetchgitPrivate somehow
<clever>
reallymemorable: it would be a string within a file, grep -r --color fetchgit -i
<clever>
reallymemorable: looks entirely normal, does `fetchgit` appear anywhere in that directory?
<clever>
reallymemorable: it could also be called default.nix
<clever>
reallymemorable: in the directory you ran nix-shell in
<clever>
reallymemorable: what is in your shell.nix?
<clever>
reallymemorable: what nix function are you calling, that results in the error your getting?
<clever>
reallymemorable: its a function, used to fetch git repos
<clever>
iqubic: ncdu
<clever>
reallymemorable: instead of using pkgs.fetchgitPrivate, you use builtins.fetchGit
<clever>
iqubic: yep
<clever>
reallymemorable: you want builtins.fetchGit
<clever>
you can also set the zfs property `com.sun:auto-snapshot:weekly=false` to just stop weekly entirely, read the description of .enable for more examples
<clever>
iqubic: you cant change how often they happen (as far as i know), but you can limit how many daily it keeps, and the same for every other category
<clever>
yeah
<clever>
reallymemorable: so, the user you login as, must never be in the nixbld group
<clever>
reallymemorable: when it selects a user, it kills everything in that user
<clever>
reallymemorable: thats the problem, nix will use the members of nixbld as build users
<clever>
iqubic: then destroy a single one of those gig large snapshots
<clever>
iqubic: you can likely get enough back to GC, from destroying 1 snapshot
<clever>
iqubic: the `used` column from `zfs list -t snapshot -r -o name,used,refer,written amd/home` tells you how much space youll get back if you destroy that 1 snapshot
<clever>
thomasd: you can also move parallel-julia up into the haskell overrides
<clever>
thomasd: instead of using pkgs.haskellPackages on line 5, use haskell.packages.ghc844, and rename the part on the left of the =, so it wont conflict with things
2019-02-18
<clever>
thomasd: can you pastebin your current default.nix file?
<clever>
spacekitteh[m]: those jobs must pass, and every single thing in the eval must finish (pass or fail)
<clever>
Alling: type will tell you if its in PATH or not, and if its a function/alias, what the definition is
<clever>
Alling: which only searches PATH, you want type
<clever>
sb0: iputils is the one nixos uses
<clever>
,locate bin ping
<clever>
Alling: you can also run `type patchShebangs` inside nix-shell to see tht
<clever>
illegalprime: yeah
<clever>
illegalprime: so it wants the cross-compiled cmake, when it shouldnt
<clever>
illegalprime: its more likely that somebody put cmake into the buildInputs, rather then nativeBuildInputs
<clever>
illegalprime: i think?....
<clever>
illegalprime: i dont think you need to cross-compile cmake, since rust doesnt need cmake at runtime
<clever>
illegalprime: yep, thats also a common thing
<clever>
Alling: its a bash function, not a binary in PATH
<clever>
illegalprime: the above files generate a linux ELF makensis binary, and some exe stubs, and makensis will then join the stubs with compressed blobs, to create working windows installers
<clever>
rydnr: can you pastebin that pharo nix expression as well, and the `nix show-derivation` of its .drv file?
<clever>
rydnr: and then you just have moz2d in your systemPackages somewhere?
<clever>
rydnr: sounds like everything should just work, how is nixos-rebuild loading that copy of nixpkgs?, what args was nixos-rebuild called with?
<clever>
rydnr: and how did you load the file from that last link?
<clever>
rydnr: and where is the nix code loading that file?
<clever>
rydnr: can you pastebin the output of `nix-diff` and also `nix show-derivation`?
<clever>
sevanspowell: its still running as the nixbld1 user, which lacks access to the socket, its better to rewrite such tests to not depend on docker
<clever>
sevanspowell: the nix sandbox doesnt allow it access to the docker socket
<clever>
rydnr: looks entirely normal, which derivation are you having trouble with?
<clever>
nisstyre: security groups must be in the resources, down between 52&56
<clever>
nisstyre: i dont see the securitygroup under resources
<clever>
nisstyre: thats a bug in nixops, it doesnt warn you when the names collide like that
<clever>
nisstyre: do the names of the machine and security group overlap?
<clever>
nisstyre: are you using --include any?
<clever>
rydnr: yeah, it will default to the arch of the nix-build binary, which we already confirmed is 64bit
<clever>
rydnr: can you pastebin your configuration.nix file?
<clever>
that looks good as well
<clever>
rydnr: what about `which nixos-rebuild` ?
<clever>
rydnr: not really
<clever>
rydnr: are you setting the system param anywhere in configuration.nix?
<clever>
rydnr: and `file /nix/store/rffcxk0l94lc96yl07r26sdnfql6x0h4-nix-2.1.3/bin/nix-build` ?
<clever>
rydnr: and what does `which nix-build` return?
<clever>
rydnr: which one is i686-linux? and what is the host cpu?
<clever>
schneid3306: if you use `#!/usr/bin/env python` and happen to have python already installed, it can work, but its often better to package the script properly
<clever>
kk
<clever>
cbarrett: what is your goal?
<clever>
i do have plans to add it to nixops in the future
<clever>
then just ssh back in, execute a second command, and it now has nixos instaled
<clever>
cbarrett: you basically build a special tarball, upload it to any linux machine, unpack it, execute 1 file, and the machine is now running nixos from a ramdisk