<clever>
cinimod: the error means it cant find that expr
<clever>
cinimod: yes, once it can eval an expr that describes how to build lapack
2021-02-12
<clever>
rauno: `nix-store --delete /nix/store/foo` will delete foo and everything that depended on it
2021-02-11
<clever>
patagonicus: the pr is still linked by number in the merge commit
2021-02-10
<clever>
dmj`: miso issues
<clever>
dmj`: your being summoned!
<clever>
i would expect that to work
<clever>
valya: are you loading the file cabal2nix generated, using haskell.packages.ghc865.callPackage?
<clever>
valya: does haskellPackages.base64 exist?
<clever>
which reminds me, some irc servers, have a special mode (+D i think?) that will hide all joins, until the user speaks
<clever>
and join lazily, as people speak
<clever>
despite the fact that matrix could have just used 1 to spy on the channel, and still inform the other invisible users about the chat
<clever>
then everybody that was active within the last month, is still returning
<clever>
danderson: i think the problem, is that matrix wants to reconnect every single idle user, even if they havent touched things in months
<clever>
danderson: :D
<clever>
yeah
<clever>
ashkitten: not sure then, also matrix has come to spam us
<clever>
ashkitten: i think that still works
<clever>
thats purely to make `nix-env -q` search recursively
<clever>
recurseIntoAttrs shouldnt be needed
<clever>
ashkitten: change the extraConfig to `FUTEX2 y` i believe
<clever>
ashkitten: an old override i have since disabled
<clever>
NF_CT_PROTO_DCCP n
<clever>
extraConfig = ''
<clever>
XXXlinux_4_9 = pkgs.linux_4_9.override {
<clever>
packageOverrides = pkgs: rec {
<clever>
netsplit is more of a problem on the freenode end of things
<clever>
looks less like a netsplit, and more like the matrix gateway died
<clever>
and we got matrix'd again, lol
2021-02-09
<clever>
PR time!
<clever>
In addition, nixos-rebuild accepts various Nix-related flags, including --max-jobs / -j, --show-trace, --keep-failed, --keep-going and --verbose / -v. See the Nix manual for details.
<clever>
nixos-rebuild still accepts --option
<clever>
--option sandbox false
<clever>
whats google say?
<clever>
i dont remember exactly why the problem happens
<clever>
pie_: the only real difference, is that it uses <nixpkgs> from outside the chroot
<clever>
pie_: have you tried nixos-install instead? thats basically a helper to run nixos-rebuild in a chroot for you
<clever>
sounds like it should allow something in $PATH
<clever>
infinisil: from `man systemd.service`
<clever>
For each of the specified commands, the first argument must be either an absolute path to an executable or a simple file name without any slashes. Optionally, this filename may be prefixed with a number of special characters:
<clever>
but .script will auto-generate a shell script for you, and then put the path of the shell-script into ExecStart
<clever>
if using ExecStart, it must be absolute, so you would do "${pkgs.go-ethereum}/bin/geth ..."
<clever>
Shell commands executed as the service's main process.
<clever>
systemd.services.<name>.script
<clever>
zceejrk: but you can instead use .script
<clever>
zceejrk: aha, ExecStart must be an absolute path, systemd rules
<clever>
nope
<clever>
so it doesnt need to be installed anywhere
<clever>
zceejrk: yeah, pkgs.geth just gets it directly from nixpkgs
<clever>
zceejrk: its supposed to be the attribute from the pkgs set, like path = [ pkgs.geth ];
<clever>
zceejrk: this lets you add packages to the PATH for a systemd service
<clever>
systemd.services.<name>.path
<clever>
Packages added to the service's PATH environment variable. Both the bin and sbin subdirectories of each package are added.
<clever>
zceejrk: you need to either define the service properly in configuration.nix, or use an absolute path under ~/.nix-profile/bin/
<clever>
zceejrk: systemd wont include nix-env'd stuff in $PATH by default
<clever>
aforemny: and then pkgs.pkgsStatic.nixos, would start from the static tree
<clever>
aforemny: the pkgs.nixos function, will eval a given nixos config, but force it to use a given pkgs tree as the base
<clever>
jybs_: if the outputs dont match bit-for-bit, the build fails
<clever>
jybs_: `repeat = 1` in `nix.conf`, makes it repeat all builds one extra time (after the normal 1 build), and then automatically compare the outputs
<clever>
jybs_: so its a question of if those directions produce the same result when run on diff machines
<clever>
jybs_: if the paths are identical, the directions on how to build the path are identical
<clever>
jybs_: only if the build is impure
<clever>
KarlJoad: thats why i prefer plain direnv without lorri, so i know when its busy
<clever>
jybs_: nope
<clever>
KarlJoad: you may also want to `echo $TEXINPUTS` to confirm its doing what you want
<clever>
KarlJoad: why did ./. fail?
<clever>
jybs_: this searches for any path signed by a given key
<clever>
sqlite> select * from ValidPaths where sigs like '%amd-1:%' limit 5;
<clever>
./. will automatically expand to the absolute path, "./." is a dumb 3 char string, that remains as-is
<clever>
KarlJoad: ./. and "./." are very different things
<clever>
KarlJoad: dont quote the path
<clever>
or nix will just refuse to download anything on the new cache
<clever>
you usually have to add the public key as well
<clever>
jybs_: once signed, anybody can host the binary cache, and the signature stops them from doing nasty things
<clever>
jybs_: mostly, your trusting the owner of the private key, who signs the paths
<clever>
KarlJoad: the same way strings and numbers can be used as values in an expr
<clever>
KarlJoad: ./. is a valid value, and can be used anywhere in a nix expression
<clever>
KarlJoad: ./. expands to an absolute path automatically
<clever>
jybs_: but i also specially configured my system to sign everything it builds (and downloads, it seems), with its own keys, so i have an extra thing i can trust, for locally built things
<clever>
jybs_: you can figure out which cache the binary came from, but not what expr was used to build it
<clever>
grawlinson: aarch64-darwin is still in beta i think
<clever>
jybs_: theres no real way to figure out which nixpkgs or expr a given path came from
<clever>
armv6l-linux has been struggling lately
<clever>
grawlinson: native aarch64-linux stuff works great, and even has coverage from hydra
<clever>
nix-store --verify-path /nix/store/foo
<clever>
but almost nothing uses the hash of the output
<clever>
when a drv is successfully built (or fetched), nix records the hash of the output into db.sqlite
<clever>
the $out path for a given drv, is then based on its hash-name.drv in some way (i forget the details)
<clever>
so it is (recursively) a hash of the build directions, and the sha256 of each source tarball
<clever>
jybs_: the hash in hash-name.drv, is purely a hash of all of the inputs (which themselves are just hashes of those inputs)
<clever>
jybs_: nix-store --verify --check-contents will review the whole /nix/store for anything that had been modified since it was built
2021-02-08
<clever>
DigitalKiwi: nope
<clever>
siraben: nix repl ~/apps/nixpkgs
<clever>
angerman: nix.extraOptions is one route
<clever>
not sure then, ive not played with nix-darwin
<clever>
angerman: what happens if you run `nix-store --verify --check-contents` ?
<clever>
angerman: it gets updated automatically when you nixos-rebuild switch
<clever>
also, MS has contributed code to the linux kernel, so MS is already on the rpi :P
<clever>
and then the tinfoil hat guys come out of the woodwork, claiming MS can gather telemetry data, before you even install vscode
<clever>
2: MS can potentially release a duplicate of some package, claiming to be newer, and since its signed with a gpg key the os trusts, it will be prefered
<clever>
1: on every `apt-get update`, it will fetch a package list from MS
<clever>
the way i look at it, that change only does 2 minor things
<clever>
slabity: the overlays are only applied to the pkgs passed to nixos modules, and nothing else
<clever>
energizer: append the strings to an existing path, such as the one you readDir'd
<clever>
so its not going to be forcing the build to be serialized
<clever>
and by that point, nix can be running each derivation in parallel, over several build machines
<clever>
energizer: i think that blog is just about how hercules can cache the IFD products, so the giant mess wont happen on the 2nd eval, assuming no changes
<clever>
energizer: doesnt help the client end, where you need to eval half the expr, download 2gig, then eval 1/4th of the expr, download another 100mb, then finish the eval, only to discover $out is already on your disk
<clever>
cole-h: possibly, ive not been keeping up with that feature
<clever>
energizer: nix cant eval in parallel, so it has to fully finish a given build, before it can eval enough to know another IFD is needed
<clever>
energizer: the problem i find with IFD, is that it forces builds to happen at eval time, and more in series
<clever>
energizer: its called recursive nix, and i think there is a branch for it
<clever>
hugolgst: i would just use runCommand to make a new derivation with the manual, and then use that as an input
<clever>
symlink is probably the simplest then
<clever>
ocharles: and you can control the name as well
<clever>
ocharles: the nixops secrets mechanism allows you to set a dest dir
<clever>
attila_lendvai: restarting lorri may also kill it
<clever>
attila_lendvai: just run the kill command on a random process within the build, and the whole build will implode due to that process failing
<clever>
and now you can freely mutate the contents of man1
<clever>
hugolgst: if you add pathsToLink = [ "/share/man/man1" ];, then it will be forced to create man1 as a directory, and fill it with symlinks to each input