2021-02-13

<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> (import <nixpkgs> {}).pkgsStatic.nixos ./configuration.nix
<clever> oops, and also a pkgsStatic...
<clever> aforemny: oops, ^
<clever> andreas303: (import <nixpkgs> {}).nixos ./configuration.nix
<clever> jybs_: but for asciidoc, it is just a timestamp in a man page
<clever> jybs_: in the gcc example from that site, it looks like the address of .fini moved by 16 bytes, for no obvious reason
<clever> jybs_: this site is doing comparisons of various things in nixos, and reporting when they differ
<clever> jybs_: https://r13y.com
<clever> nope
<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> [root@amd-nixos:~]# sqlite3 /nix/var/nix/db/db.sqlite
<clever> jybs_: if you revoke the key, it will stop downloading the paths, but it will keep anything already in the store
<clever> jybs_: each cache will advertise a priority, and nix sorts them internally
<clever> Priority: 40
<clever> [root@amd-nixos:~]# curl https://cache.nixos.org/nix-cache-info
<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> "amd-1:Ka2xcf8spxbZXhfogPgmNInU659vhnKx0NQrPddGHmP10wiu3UzR5l4FLI6G+rwELg6yekxUHRIRdAeyh0TfAQ==",
<clever> jybs_: this says that the path containing zpool, was signed by cache.nixos.org
<clever> "cache.nixos.org-1:ztq9SMyMeuhMDRTuOH6BQSWXHlWCzdfmThfbBQ+nbbIDv41x3orG3wmy0kg2TYGfnwr+kiUnve6o0l1xLiIQDA=="
<clever> "signatures": [
<clever> nix path-info --json $(realpath $(which zpool)) | jq
<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> this is the latest one
<clever> there have been over 10 threads on the rpi forums, demanding to remove MS spyware from the os
<clever> so you can just "apt-get install vscode"
<clever> to make installing vscode easy, microsoft servers and gpg keys are loaded into apt
<clever> and to make using it easy, they have vscode support
<clever> the rpi foundation released a new micro-controller
<clever> no, a new one, lol
<clever> matthewcroughan: have you heard about the MS mess on rpi?
<clever> matthewcroughan: heh
<clever> manage starting all builds
<clever> EdLin: only nix-daemon will use that tempdir, and nothing else
<clever> slabity: thats for adding extra stuff into the sandbox, in addition to the normal tempdir
<clever> (in configuration.nix)
<clever> to change where nixos keeps that tempdir
<clever> systemd.services."nix-daemon".environment.TMPDIR = "/anywhere";
<clever> if your on nixos, then its definitely running
<clever> is nix-daemon running?
<clever> EdLin: if your using nix-daemon, then its the $TMPDIR of nix-daemon, not nix-build
<clever> EdLin: just change $TMPDIR
<clever> nix just puts the tempdir in whatever $TMPDIR is set to
<clever> [Service]
<clever> Environment="TMPDIR=/mnt/tmp"
<clever> pi@pi400:~ $ cat /etc/systemd/system/nix-daemon.service
<clever> one sec
<clever> slabity: it can be simpler if you already have such an overlays dir in your flake
<clever> and nix will apply it for you
<clever> patches = [ ./foo.patch ];
<clever> or a .patch file
<clever> yeah
<clever> havent heard of him before
<clever> jgart[m]: the install section just blindly tries to fetch *facepalm*: https://github.com/LukeSmithxyz/st/blob/master/Makefile#L42-L44
<clever> jgart[m]: generally, the code should never be doing fetching at build time, so you need to figure out why its doing so and disable it
<clever> it might be linked there, i never actually looked
<clever> ,commands
<clever> ,
<clever> so you dont have to do that dance on every single rebuild
<clever> thats why my expr uses a constant in $NIX_PATH, and then swaps out the symlink at that constant path
<clever> so you have to fully logout, or ssh back into yourself
<clever> it may also inherit the env vars from the window manager
<clever> slabity: env variables only update if you relaunch the shell
<clever> ,locate
<clever> nixpkgs adds the .dev for you, so just buildInputs = [ xorg.libXft ];
<clever> ,locate Xft.h
<clever> yeah, since your linking against it
<clever> like this one
<clever> > xorg.libX11
<clever> jgart[m]: one of these attributes
<clever> > xorg
<clever> if your linking to it, buildInputs
<clever> if its ran at build time, nativeBuildInputs
<clever> slabity: get off my lawn!, *shakes cane*
<clever> when possible
<clever> hence why its better to limit your msg to 1 line, so it just goes thru irc as normal
<clever> exactly
<clever> not sure
<clever> jgart[m]: for example, this didnt really need to go thru the auto-pastebin: https://matrix.org/_matrix/media/r0/download/matrix.org/TGjSXDZlYYymrMYfbgzqzkhN/message.txt
<clever> jgart[m]: when possible, try pasting just 1 line, so it goes thru irc like normal
<clever> this could also work, but is rather long
<clever> `wget https://github.com/lukesmithxyz/st` gives html, not the real source
<clever> jgart[m]: and hashes the result
<clever> jgart[m]: `nix-prefetch-url` basically just runs wget on the url
<clever> cole-h: at one point, there was a bug in nix, where leaving it blank allowed unvalidated network, lol
<clever> ,tofu jgart[m]
<clever> slabity: a function for loading a flake from non-flake code
<clever> shove that into a foo.nix, and it will behave identically to the foo overlay in the flake
<clever> (builtins.getFlake (toString ./.)).overlays.foo
<clever> write a file that will import the given overlay
<clever> slabity: there is no real way to turn the expr back into a file, so you need to start with it already in files
<clever> > builtins.toFile "foo.txt" "contents"
<clever> aleph-: yeah, all of them return a path
<clever> and writeTextFile takes a set, and writes a file at build-time
<clever> writeText is a wrapper over writeTextFile
<clever> toFile happens at eval time, and behaves identically to ./foo.txt
<clever> aleph-: pkgs.writeText and builtins.toFile
<clever> DigitalKiwi: more, that the flake is pure, and wont load any overlays in $HOME, only overlays the flake said to load
<clever> ive only used it for basic packaging so far, not nixos level things
<clever> that complicates things a bit more
<clever> the flake puts your entire repo as one dir in the store, and files can cross-reference within that dir
<clever> relative paths still work fine
<clever> and then build nixpkgs.overlays by just importing every file in that dir
<clever> slabity: it needs to eval to a path, thats best done by having all of your overlays in the form of ./overlays/foo.nix
<clever> slabity: line 13&17 of the file i just linked
<clever> slabity: this arranges for a directory of overlays to be the system-wide default, and also (at one time) loads the overlays into nixos
<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

2021-02-07

<clever> ,unstable
<clever> shapr: environment.systemPackages = [ (pkgs.callPackage ~/foo.nix {}) ];`
<clever> shapr: add it to the environment.systemPackages list in configuration.nix
<clever> ,-A jawr

2021-02-06

<clever> you probably just want a normal nixos config
<clever> like any other nixos option
<clever> asymmetric: you can still set the _modules thing a second time, with mkForce i believe
<clever> asymmetric: you should only ever be passing args via that mechanism, or the normal config system
<clever> asymmetric: yep
<clever> asymmetric: in any nixos module
<clever> asymmetric: _module.args.custom_arg = 42;
<clever> asymmetric: ive not investigated the nixos flake stuff yet
<clever> asymmetric: this is how you add custom args in a normal nixos, and anything in that modules list can be a naked module (just an attr set)
<clever> 222 _module.args = {
<clever> 223 pkgs = finalPkgs;
<clever> [clever@amd-nixos:~/apps/rpi/rpi-tools]$ vi ~/apps/nixpkgs/nixos/modules/misc/nixpkgs.nix

2021-02-05

<clever> eyJhb: you can also run `nix-store --query --roots /nix/store/foo`, to see why foo is rooted
<clever> ornxka_: yeah, the unpackPhase copied it to . for you

2021-02-04

<clever> ornxka_: the patch is applied to the src in . before the build starts
<clever> matthewcroughan: overrides against glibc arent easy, so its simpler to just edit nixpkgs directly
<clever> what args did you run nix-build with, exactly?
<clever> nix-shell -p will try to look for <nixpkgs> by default, and `-I ../path` makes it check for a `../path/nixpkgs`
<clever> matthewcroughan: `-I ../path` shouldnt work on either
<clever> matthewcroughan: example?
<clever> fuiltilt: hmmm, yeah, i'm not sure where its coming from either, but the above {^_^} bot shows that it is there
<clever> > "${xorg.libX11.man}"
<clever> > "${xorg.libX11.dev}"
<clever> > "${xorg.libX11.out}"
<clever> and also $dev
<clever> > xorg.libX11.outputs
<clever> its a split-output package, where it will have a $out and a $man
<clever> fuiltilt: the outputs array contains "man"
<clever> fuiltilt: also try referencing the gist i gave, and add in xorg.libX11.man

2021-02-03

<clever> fuiltilt: https://gist.github.com/cleverca22/b8f9f73372fe4585d29706c7a9fd83c8#file-gistfile1-txt-L13-L19 is how i got a range of man pages, but i dont know if X is within that set
<clever> ,locate brcmfmac43012-sdio.bin
<clever> with exactly that name
<clever> yep!
<clever> (clang 7)
<clever> clangStdenv properly routes everything to clang
<clever> Yaniel: that wont work right, $CC will still point to gcc

2021-02-02

<clever> tobiasBora: thats the variant ive been using
<clever> tobiasBora: oh, thats new
<clever> tobiasBora: `nix` will reveal all!
<clever> tobiasBora: also, nix edit -f '<nixpkgs>' steam-run
<clever> tobiasBora: <nixpkgs/nixos> is the path to nixos, not pkgs
<clever> and knowing that steam-run is just steam.run, you can then ask, where was the run=
<clever> > builtins.unsafeGetAttrPos "run" pkgs.steam
<clever> and this
<clever> 25206 steamPackages = dontRecurseIntoAttrs (callPackage ../games/steam {
<clever> and if you then go there, youll find this
<clever> 25210 steam = steamPackages.steam-fhsenv;
<clever> 25211
<clever> 25212 steam-run = steam.run;
<clever> tobiasBora: this will instead say where the steam-run= is, in all-packages.nix
<clever> > builtins.unsafeGetAttrPos "steam-run" pkgs
<clever> that one is via runCommand i believe
<clever> tobiasBora: this is also handy, to know where the source is
<clever> > ninja.meta.position
<clever> so just adding them to the inputs for a drv magically changes how the stdenv behaves
<clever> and meson has the same, mesonConfigurePhase
<clever> tobiasBora: this defines a ninjaBuildPhase, and also does `buildPhase=ninjaBuildPhase`
<clever> cat result/nix-support/setup-hook
<clever> nix-build '<nixpkgs>' -A ninja --option min-free 0
<clever> tobiasBora: packages like ninja can contain a setup hook, which mutates the default phases
<clever> yeah, that would help
<clever> i generally use gdb to figure out where the problem is, then an overlay to rebuild just one thing with debug
<clever> truby: this function can be ran on any package, to make a debug variant of that
<clever> nix-repl> enableDebugging hello
<clever> «derivation /nix/store/3vvfczijxs5nrdj64b048k50wq2rpjpr-hello-2.10.drv»
<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
<clever> *looks*
<clever> hugolgst: and now all of $out/share is read-only
<clever> hugolgst: if only one input to the buildEnv has a share dir, then $out/share is a symlink to that one input

2021-02-01

<clever> fresheyeball: restart nscd.service
<clever> nix build .#defaultPackage.x86_64-linux