<clever>
d1rewolf: i dont really use the nix-env search, i just tab-complete in nix repl
<clever>
infinisil: it also happens with dynamic ones
<clever>
so when you try to lookup .foo.bar, it will find foo in the hash table, then use its index to search the set
<clever>
tilpner: all strings being used as keys in sets are put into a global hash table, so the keys in the set are actually integers
<clever>
d1rewolf: only nix-env supports installing a set, nix config files need you to give a list of packages
<clever>
d1rewolf: jetbrains is not of type package, it is of type set
<clever>
d1rewolf: run `nix repl '<nixpkgs>'` then eval `jetbrains` inside there
<clever>
d1rewolf: jetbrains is a set of packages, if you tell nix-env to install jetbrains, it will instead install everything inside jetbrains
<clever>
tilpner: a set is a strict list of keys and values, and all keys must be known before any can be accessed
<clever>
tilpner: dont think that is possible
<clever>
d1rewolf: when you ask nix-env to search, it may not show all attributes within jetbrains, so jetbrains.jdk wont appear
<clever>
d1rewolf: nix-env doesnt recurse into everyting on its own
<clever>
you can also do [ pkgs.android-studio ];
<clever>
do you have a with pkgs; nearby?
<clever>
hmmm, and android-studio is the attr path
<clever>
d1rewolf: the nix files need attribute paths, not names
<clever>
rotaerk: i think nixon is special, us president
<clever>
america wont let nix have the doman :P
<clever>
that reminds me, nixcon.com cant be registered, because of its edit distance from nixon.com
<clever>
--ignore-liveness still wont corrupt the store, but it can delete important paths that leave the machine unusable
<clever>
and nix-channel was refusing to download the new tar until an hour had passed
<clever>
its far more likely, that you messed up the tar on your first test, and ~/.cache/nix/tarballs was caching the contents of the tar for 1 hour
<clever>
thats the whole point of nix
<clever>
zgrep: and because of how nix works, deleting things like that is pointless, nix will perfectly recreate the exact same files at the same paths every time
<clever>
it can delete the current nix-env profile, and basically uninstall ALL programs at once
<clever>
if you --ignore-liveness, you risk seriously breaking the machine
<clever>
so it will always create the same contents
<clever>
the caching is based on a hash of the build directions
<clever>
what do you get when you ls ~/.nix-defexpr/channels/ ?
<clever>
shouldnt
<clever>
zgrep: works as expected on this end, one symlink to the dir, and all the files inside that
<clever>
infinisil: then you need to find the derivation that includes the libs, and add it to buildInputs
<clever>
and we are getting matrixed again
<clever>
infinisil: is opencl in buildInputs?, does its lib exist in ${opencl}/lib/ ?
<clever>
dhess, jgt: its safer to push just the closure of the program, rather then the entire nixops deployment, and to also never give the package build the secrets
<clever>
jgt: i found some "secrets" in the closure of hydra
<clever>
bennofs: you can either run the indexer against the release.nix file, or directly run hydra-eval-job against release.nix
<clever>
d1rewolf__: what file did you set allowUnfree in?
<clever>
d1rewolf__: nix-env obeys the per-user nixpkgs config, not configuration.nix
<clever>
bennofs: it has some perl based scripts in it
<clever>
d1rewolf__: the attribute paths are google-chrome for the pre-compiled blob and chromium for the opensource one (also precompiled, but by hydra)
<clever>
or -A out -A doc
<clever>
sphalerite mentioned the all attribute, so try -A all
<clever>
a.b is an attribute path
<clever>
> ({ a = { b = 2; }; }).a.b
<clever>
a path you form from multiple attributes
<clever>
fresheyeball: it then reads attributes from the file it loaded
<clever>
fresheyeball: -A takes an attribute path
<clever>
fresheyeball: then use nix-build -A doc
<clever>
fresheyeball: what command do you run to build the package?
<clever>
fresheyeball: nix must always build all outputs at the same time
<clever>
fresheyeball: try adding .doc to the attr path
<clever>
booglewoogle: does it behave differently if you run `sudo -i` then seperately run `nixos-rebuild switch`
<clever>
sphalerite: ah maybe, the above have different timestamps
<clever>
because its meant for keys that are never meant to enter the store
<clever>
ocharles_: i think nixops is doing some funny things, and wont build the derivation
<clever>
d1rewolf_: youll need to write a nix file to package that shellscript, and apply sed to it
<clever>
d1rewolf_: if that string is within a nix file, it will automatically expand to /nix/store/0zxf7wj1sj10zj74kck0faqfzk8z7gi3-i3blocks-1.4/libexec/i3blocks
<clever>
d1rewolf_: run something like sed over the script to insert ${pkgs.i3blocks}/libexec/i3blocks into the script
<clever>
the /etc stuff has text and source, but deployment.keys decided to rename it
<clever>
ocharles_: ah, yeah, its keyFile
<clever>
hmmm, *checks docs*
<clever>
ocharles_: deployment.keys.<name>.source
<clever>
ocharles_: i think you want .source
<clever>
i dont think it will
<clever>
and pass the derivation the storepath of the snapshot
<clever>
each time you deploy, nix will snapshot that directory and store it in the local /nix/store/
<clever>
and then modifying it to take a snapshot of the keybase files
<clever>
ocharles_: id recomend passing "${/keybase}" to the dhallToNix script as well
<clever>
yeah, since your using deployment.keys, it will copy to the specified path on the server, outside the store
<clever>
ocharles_: the output of that will land in /nix/store/ and be readable to all users on the machine
<clever>
ocharles_: can you gist your current nix file?
<clever>
ocharles_: when done correctly, its read directly by the python code in nixops
<clever>
ocharles_: nixops deployment.keys are not read by the nixbld group
<clever>
coconnor: i believe its pavucontrol
<clever>
coconnor: if you check pavucontrol, do you see several streams on the playback tab?
<clever>
yeah
<clever>
and a trojaned copy of the source will always live in a different directory and be ignored
<clever>
mightybyte: so somebody wanting an un-trojaned copy, will be using the hash of the unmodified source
<clever>
mightybyte: the hash of that storepath is based on the contents of the directory
<clever>
mightybyte: because a malicous user can just give the daemon a trojan'd copy of sudo, and wait for it to be ran as root
<clever>
mightybyte: but then the rules of the store cant easily be enforced, and a multi-user setup would become a security problem
<clever>
mightybyte: only if /nix/store is user writeable can you run without the daemon, and then nix-build just spawns the ssh directly as your user
<clever>
and either way, things get cached in /nix/store and become world readable
<clever>
theres not really a way to give just one user access to the cache
<clever>
dedicated just to the cache use
<clever>
mightybyte: i would just generate a new private as root
<clever>
mightybyte: each user or machine has their own private for accessing the cache, and then the cache has a whitelist of publics that can read it
<clever>
mjhoy: where does ~/.nix-profile point when you ls -l ?
2018-07-19
<clever>
and i need to get off to bed, goodnight
<clever>
boomshroom: oh wow, nice find with that site
<clever>
boomshroom: what happens if you run evtest (from the evtest package) as root?
<clever>
xinming: heading off to bed now, goodnight
<clever>
xinming: try adding preConfigure = "export LD_LIBRARY_PATH=${openssl.out}/lib"; and see if that makes a difference
<clever>
xinming: that also works
<clever>
xinming: can you gist the current nix expression?
<clever>
xinming: what happens if you set LD_LIBRARY_PATH=${openssl.out}/lib/ ?
<clever>
and why is it also looking in glibc??
<clever>
./logfiles.5427:openat(AT_FDCWD, "/nix/store/l0adcz8y05vajfi483a7qv31i03rspqq-glibc-2.27/lib/libssl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
<clever>
xinming: also, why is that working?, are you not on nixos?
<clever>
xinming: you need to fix perl to not be stupid