2020-07-25

<clever> installingNIX: yeah
<clever> adyatlov: then add pkgs to the args where it gets every other package
<clever> adyatlov: if your not changing common.nix, you can just do (pkgs.path + "/nixos/pkgs/applications/editors/jetbrains/common.nix") for its path
<clever> zeta_0: maybe
<clever> not sure
<clever> installingNIX: if you enable xfce, it installs it for you
<clever> installingNIX: download finished, its 2.1gig
<clever> installingNIX: github is also rather slow at generating those files, i have fiber internet, and its still not done
<clever> zeta_0: you want to put that function into its own file, and then do (pkgs.callPackage ./ownfile.nix {})
<clever> zeta_0: line 23-37 is defining a function, but you jammed it into the middle of buildInputs, which wants a derivation
<clever> installingNIX: only if you want them
<clever> installingNIX: or not install nerd-fonts
<clever> installingNIX: all you can do is wait
<clever> installingNIX: github also doesnt report the size of the file, so you have no progress information
<clever> installingNIX: its downloading nerd-fonts, which is a fairly big file
<clever> installingNIX: what about urls?
<clever> installingNIX: srcs, not source
<clever> installingNIX: just run cat on it then, what is the srcs ?
<clever> installingNIX: no, the check is checking if the path begins with /nix/store/
<clever> installingNIX: you dont need to
<clever> installingNIX: its in /mnt/nix/store/
<clever> installingNIX: run `nix show-derivation` on that drv, what is the srcs?
<clever> installingNIX: what is it downloading?
<clever> installingNIX: requireFile never downloads anything
<clever> adyatlov: you can also newPkgs.path to get the path
<clever> adyatlov: fetchTarball returns the path to nixpkgs
<clever> read the old expr, or fork nixpkgs
<clever> you need to callPackage common.nix yourself
<clever> it winds up using the old name
<clever> adyatlov: also, the funcion for packaging jetbrains things does ${name}, so you cant override the name
<clever> adyatlov: that string is in the name field your setting
<clever> installingNIX: yeah
<clever> adyatlov: is the hash correct?
<clever> adyatlov: the pair of overrideDerivation and (old: { ..}) needs another () around the whole pair
<clever> adyatlov: no, add more!
<clever> adyatlov: you have a list with 2 functions, not the result of applying the function on the value
<clever> > let func = a: b: a*b; in [ func 2 3 ]
<clever> adyatlov: () are the problem
<clever> installingNIX: probably
<clever> adyatlov: yep
<clever> adyatlov: yeah
<clever> installingNIX: the problem is because oracle is being sneaky, and changing the contents of the tar while claiming its the old one
<clever> adyatlov: ah, that one only has overrideDerivation for a weird reason
<clever> installingNIX: it just gives you an error, telling you to go to the given page and download it yourself
<clever> installingNIX: requireFile is a special function, for files nix cant download on its own
<clever> installingNIX: thats why i said that `src = ./jdk-8u261-linux-x64.tar.gz` would be a much simpler override
<clever> oraclejdk8.overrideAttrs (old: { src = requireFile { name = "jdk-8u261-linux-x64.tar.gz"; url = "http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html"; sha256 = "hashgoeshere; })
<clever> 2020-07-25 19:38:53 < clever> installingNIX: you need to read the old expression, and then copy/paste the requireFile part over, changing the hash
<clever> the file it opens is read only
<clever> it will insert the current host platform (32bit or 64bit) into that, and do something like sha256.x86_64-linux
<clever> installingNIX: the "sha256" matches the 3rd parameter, called "sha256"
<clever> installingNIX: line 84, is referencing the function argument on line 3
<clever> yes
<clever> installingNIX: 1-6 of the nix file
<clever> installingNIX: but if your overriding the hash, you can just skip that, and do sha256 = "hashgoeshere";
<clever> installingNIX: lines 1-6 define a function that takes 5 arguments, the 3rd one being sha256, a set from platform to hash
<clever> installingNIX: the drv file is much easier to read if you run `nix show-derivation` on it
<clever> ,paste installingNIX
<clever> installingNIX: run `nix edit nixpkgs.oraclejdk8` to see the old expr
<clever> installingNIX: you need to read the old expression, and then copy/paste the requireFile part over, changing the hash
<clever> > :p [ {a="set";} 1 "two" true ]
<clever> yep, a list can have a mix of any type
<clever> > :p let func = a: b: a*b; in [ (func 2 3) ]
<clever> > let func = a: b: a*b; in [ (func 2 3) ]
<clever> yeah
<clever> list has higher priority, so it makes an array of 3 elements, instead of running the func
<clever> > let func = a: b: a*b; in [ func 2 3 ]
<clever> except when you have a list
<clever> installingNIX: any time you have more then 1 value in a place that you expected just 1 value, the 1st one is a function
<clever> without () around it
<clever> installingNIX: the () is needed, because the old: {} cant parse right
<clever> > let func = a: b: a*b; in func 2 3
<clever> installingNIX: nope, its a method because there is an argument after it
<clever> adyatlov: yes
<clever> installingNIX: yes
<clever> adyatlov: you have to use overrideAttrs and change the name and src
<clever> adyatlov: nope, version isnt an argument to the file, so .override cant change it
<clever> ,pills installingNIX
<clever> installingNIX: old: { ... } is then another function, that is given the old set, and returns a set of things to change
<clever> installingNIX: and then it is followed by an argument in (), so treat overrideAttrs as a function, and call it
<clever> installingNIX: oraclejdk8.overrideAttrs says to look at the attribute on oraclejdk8 that is called overrideAttrs, exactly the same as object.attr would in js or c++
<clever> installingNIX: it would be more like oraclejdk8.overrideAttrs (old: { src = requireFile { hash = "..."; something = "something"; })
<clever> installingNIX: outputHash isnt a function
<clever> installingNIX: yeah, thats probably simpler
<clever> installingNIX: .withPackages is a python only thing
<clever> installingNIX: you want something like oraclejdk.overrideAttrs (old: { src = ./path/to/file.tar.gz; })
<clever> installingNIX: very, thats why you do an override in the expression
<clever> adyatlov: only the process triggering the build can get realtime logs
<clever> installingNIX: its the outputHash
<clever> installingNIX: run `nix show-derivation` on the failing .drv file
<clever> adyatlov: `nix-store -l` and `nix log` can read them
<clever> adyatlov: nope, the logs always go to /nix/var/log/
<clever> you can do a package override against it, as with any other package
<clever> yeah
<clever> installingNIX: the .tar.gz you download, must be binary identical to the one nix is expecting
<clever> its the old (and semi stupid) notion, that anything that needs root, belongs in sbin, and you can then omit it from non-root $PATH
<clever> '';
<clever> wrapProgram ...
<clever> ${old.postFixup}
<clever> energizer: you want postFixup = ''
<clever> energizer: the fixup phase moves everything in sbin to bin, but your using preFixup, so it hasnt been moved yet!
<clever> energizer: its in $out/sbin/
<clever> libtool: install: /nix/store/x0jla3hpxrwz76hy9yckg1iyc9hns81k-coreutils-8.31/bin/install -c .libs/airodump-ng /nix/store/isglw783kbjcli13a02kb4yhl352wpc8-aircrack-ng-1.6/sbin/airodump-ng
<clever> energizer: well, it at least compiled it...
<clever> CC src/airodump-ng/airodump_ng-airodump-ng.o
<clever> configure likely said why
<clever> check the output that ./configure printed?
<clever> energizer: airodump-ng truely doesnt exist!
<clever> energizer: add `ls -lh $out/bin/` to the preFixup, what is in there?
<clever> energizer: when does it complain? when building aircrack-ng?
<clever> energizer: you want wrapProgram and --prefix PATH
<clever> energizer: propagatedBuildInputs is only available at build time, for other things that depend on that package
<clever> hazel[m]: i also tend to put each virtualhost for nginx into its own module, so i can move that host to another box, with minimal effort
<clever> it then branches out, to various feature files, and most end in core.nix
<clever> every machine starts at a note, like nas.nix or laptop.nix
<clever> similar here, ive got a bit of a mix of 2 trees
<clever> not sure how icecast and rtmp can interact though
<clever> i like the idea of having nixos host everything, dont rely on any outside distro's
<clever> hazel[m]: here is the server end of rtmp, https://github.com/cleverca22/nixos-configs/blob/master/rtmp.nix
<clever> something to do with the state in xorg for me, causes obs to leak a gig of swap every 5 seconds
<clever> but the obs client leaks memory hard lately
<clever> ive use obs-studio before, with rtmp hosted by nginx under nixos
<clever> guessing its audio only?
<clever> ah, now it has a gui
<clever> the help isnt very helpful
<clever> [clever@amd-nixos:~/apps]$ result/bin/butt --help
<clever> [clever@amd-nixos:~/apps]$
<clever> hows it started?
<clever> hazel[m]: i can hear some music
<clever> libjpeg into buildInputs, and it builds
<clever> libjpeg.out 0 s /nix/store/fglwxpvjlp640bysv8lqyg637gn7cm7b-libjpeg-turbo-1.5.1/lib/libjpeg.so
<clever> [clever@amd-nixos:~/apps]$ nix-locate libjpeg
<clever> thats what happens when you assume the cause of an error
<clever> it failed to compile, therefore, malloc doesnt work!!
<clever> hazel[m]: it tries to link with jpeg, when testing if malloc works
<clever> hazel[m]: (facepalm)
<clever> /nix/store/klg7ribk7f834yb0hn1fxs6653wzlncb-binutils-2.31.1/bin/ld: cannot find -ljpeg
<clever> hazel[m]: and if you build with --keep-failed, and it fails, you can read config.log...
<clever> maybe --enable-malloc?
<clever> hazel[m]: does ./configure --help show anything relevant?
<clever> hazel[m]: i think this is your problem
<clever> checking for GNU libc compatible malloc... no
<clever> autom4te.cache/traces.1:m4trace:configure.ac:153: -1- AH_OUTPUT([malloc], [/* Define to rpl_malloc if the replacement function should be used. */
<clever> hazel[m]: its definitely configure thats doing it, maybe it has an off swich?
<clever> configure:$as_echo "#define malloc rpl_malloc" >>confdefs.h
<clever> patches = [ ./foo.patch ];
<clever> so id say config.h is to blame, and that line should be killed
<clever> config.h is trying to remal malloc to rpl_malloc, but rpl_malloc doesnt exist
<clever> ../config.h:169:16: error: 'rpl_malloc' was not declared in this scope 169 | #define malloc rpl_malloc
<clever> hazel[m]: got the full error, i just build the above nix
<clever> can you pastebin the full error output?
<clever> then it wasnt reconf
<clever> hazel[m]: nativeBuildInputs is for tools used at build time, buildInputs is for libraries used at runtime
<clever> hazel[m]: `nativeBuildInputs = [ autoreconfHook ];` will run reconf for you

2020-07-24

<clever> praduca: you can use mkForce to force your own choice onto that option
<clever> in the end, it still evals down to a .drv file, and nix-daemon builds it as normal
<clever> yeah, thats a lisp based expression language, ontop of the existing nix-daemon and drv files
<clever> it cant be un-parsed
<clever> no real way to undo that
<clever> they turn into pointers to c++ functions
<clever> functions dont even remain intact
<clever> and `1 * 2` turns into `__mul 1 2`
<clever> <nixpkgs> magically turns into __findFile __nixPath "nixpkgs" i believe
<clever> cant easily do that, because the nix parser mutates the syntax a lot
<clever> that write an expression to a file, and then 11 points NIX_PATH to it
<clever> ashkitten: line 5-6
<clever> ashkitten: though if the $HOME overlays are missing, it doesnt amtter as much
<clever> ashkitten: i think that has priority over the ones in $HOME
<clever> ashkitten: lines 10-14 will setup $NIX_PATH to look for overlays in /run/current-system/overlays, and line 17 will then put the overlays there
<clever> cole-h: the problem is specific to that version of nixops i believe
<clever> adisbladis: where is your purity now? :D
<clever> gchristensen: it will impurely load the config.nix and overlays from $HOME
<clever> gchristensen: that forces every machine in the cluster to use a single instances of pkgs, and ignore nixpkgs.overlays/nixpkgs.config
<clever> gchristensen: oh, are you setting nixpkgs.pkgs via nixops?
<clever> gchristensen: are you able to reproduce the issue with a minimal set of nix files you can publish?
<clever> cab404[m]: nix always disables the network while building things, so you cant clone things like that
<clever> gchristensen: any containers at play? or nixpkgs.pkgs ?
<clever> cab404[m]: need more context, what derivation caused it?
<clever> cab404[m]: sounds like the network sandbox is doing its job perfectly
<clever> Fare: then nix-build it, and read the file it generated
<clever> Fare: try doing `runCommand "test" { buildInputs = [ git ]; } "cp -r ${./.git} .git; git describe --tags --always output > $out"`
<clever> Fare: thats where commitIdFromGitRepo is better
<clever> Fare: it returns all 0's if the tree is dirty, if you have any changes at all
<clever> dont know
<clever> noonien: you can override the url it will look at
<clever> hashed-mirrors = http://tarballs.nixos.org/
<clever> nix show-config | grep hashed-mirrors
<clever> for any open-source fixed-output derivation in nixpkgs, the tarball gets uploaded there, indexed by hash
<clever> noonien: the tarball mirror at tarballs.nixos.org does sorta do the same thing
<clever> noonien: you can also just do `hello.overrideAtts (old: { src = ./hello.tar.gz; })` to force it to use a given tar, in your repo
<clever> noonien: or host a copy of the .tar.gz yourself somewhere
<clever> noonien: ahhh, so when the deps go away, yeah, thats where github can help, repos are less likely to vanish
<clever> noonien: i just commit the default.nix to the project, and then anybody that clones it can just nix-build, and it builds
<clever> noonien: just put a default.nix in the project, and run nix-build on it
<clever> noonien: and for disk usage, `du -hc --max=0 $(nix-store -qR $out) | sort -h`
<clever> noonien: nix-store --query --deriver
<clever> not sure, you may need to just run `git log` in a derivation that includes `.git`
<clever> noonien: run `nix-store -q --tree` on both the $out and the drv file
<clever> Fare: you should also look into lib.commitIdFromGitRepo too
<clever> Fare: try using that instead?
<clever> cole-h: thats the one!
<clever> Fare: one of many solutions, is to just run builtins.fetchGit ./., the attr set returned tells you the git revision, if its clean
<clever> gchristensen: what was the function called? i'm drawing a bit of a blank.....
<clever> Fare: there are already pure nix exprs to do exactly that
<clever> Fare: what are the contents of build.ss?
<clever> Fare: that sounds like something you can do without recursive nix
<clever> Fare: running nix-build inside a nix build
<clever> another anoyance, that pure nix kinda forces on you (but recursive nix solves), is that you have to re-compres the layers each time you build
<clever> so you could build 3 or 4 images, run X on all 4, then get a tuned config blob
<clever> maybe something like PGO, where you give it a blob from past analasis?
<clever> yeah, and that can be tricky
<clever> though you may want some dummy config to delta, and see how much the layers changed
<clever> yeah, since its a pure function and doesnt depend on deltas, you can easily generate it for any given package, at the current ver
<clever> so my savings are <50% of the total image
<clever> my problem, is that the last layer is almost always larger then every other layer combined
<clever> what about spreading the bulk evenly?
<clever> usually with 3 manual layers, common unixy tools, the app itself, a shell sript to launch the app
<clever> ive found things simpler, to juse use the non-layered function, and chain it
<clever> and the grouping always happens at the last layer
<clever> its not able to group things together, until it runs out of layers
<clever> gchristensen: ah, that would explain the problems ive been seeing
<clever> i'm thinking anything you didnt name, just goes into its own layer(s) as before
<clever> Fare: i have seen problems where there are to many layers and it tends to make a 1gig layer at the end
<clever> gchristensen: outer list is layers, inner lists are derivations
<clever> gchristensen: a list of lists maybe?
<clever> you dont really want to use /. you want to always start with something relative like ./.
<clever> /. i knew of
<clever> pie_: /. or toPath?
<clever> what do the logs say?
<clever> mostly, info relating to the copy of grub in the MBR
<clever> so it knows when to re-run grub-install
<clever> infinisil: grub does something similar, via /boot/grub/state
<clever> infinisil: compare the kernel in /run/booted-system and /run/current-system ?
<clever> Church-: nix.package can be used to force a different derivation for the nix binary
<clever> alexissa: the true error is hidden by parallel jobs, try again with `--option cores 1`
<clever> ah, dont know about that
<clever> Church-: you could add a checkPhase that runs the binary in some way
<clever> [root@amd-nixos:~]# nix-channel --list
<clever> yep
<clever> Church-: you need to either update the nixos channel or set nix.package in configuration.nix and then nixos-rebuild
<clever> Church-: nixos or other?

2020-07-23

<clever> energizer: not really, because self is the same for every overlay, but super is different for each overlay
<clever> you usually use self, but sometimes need super to avoid infinite recursion
<clever> super is the previous version of pkgs, self is the final version with the overlay included
<clever> wucke13: have you tried as an overlay instead? nixpkgs.overlays = [ (self: super: { unstable = ...; enlightenment = { enlightenment = self.unstable.....; }; }) ];
<clever> wucke13: does it say which line and column the error is on?
<clever> wucke13: try removing the `rec` on line 1
<clever> arianvp: https://status.nixos.org/ this will tell you which hydra jobset is responsible for each nix channel
<clever> yeah, hydra is more about building things then causing side-effects
<clever> arianvp: make sense so far?
<clever> if you switch to the jobs tab, youll see the 6 attributes in my release.nix, and their status over time
<clever> so hydra will just fetch the latest version of that branch for both repos, and then build every attribute in the given release.nix
<clever> and then up a bit under `nix expression`, it says to run release.nix from the input called nixos-configs
<clever> the inputs tells hydra to fetch nixos-configs and nixpkgs-channels, using the branches master and nixos-unstable-small
<clever> arianvp: first, start on a configuration tab like this
<clever> why?
<clever> arianvp: hydra can also generate graphs showing the closure size
<clever> arianvp: i notice that the new yubikey-agent doesnt respect its own enable flag, and will always be installed!
<clever> arianvp: the diff to nixpkgs that triggered the build, and what stuff it had to rebuild for the nas
<clever> it gc roots everything on itself, so it doesnt have to fetch things from a cache every time it starts up
<clever> i use hydra for building my nixos images
<clever> not sure
<clever> its not on system wide, but certain things that are cheap to build, are just always built
<clever> 2020-07-23 20:09:33 < clever> and both flags are per-derivation things
<clever> arianvp: this flags all unit-script derivations to avoid build machines, and never query the cache
<clever> 85 preferLocalBuild = true;
<clever> 86 allowSubstitutes = false;
<clever> 74 writeTextFile =
<clever> 205 in pkgs.writeTextFile { name = mkScriptName name; executable = true; inherit text; };
<clever> 204 let mkScriptName = s: "unit-script-" + (replaceChars [ "\\" "@" ] [ "-" "_" ] (shellEscape s) );
<clever> run nix-diff on the 2 versions
<clever> and both flags are per-derivation things
<clever> nope, both are off by default
<clever> it will still try to query the cache, which is disabled via a 2nd flag
<clever> arianvp: i believe preferLocalBuild just stops it from using build machines, when possible
<clever> ornxka_: you can change that to a lower number, or gc -d to delete generations
<clever> ornxka_: the last boot.loader.grub.configurationLimit generations of nixos are copied to /boot on each switch
<clever> --fast will still copy all of the secrets to /boot/ every time
<clever> dejanr: initialPassword only takes effect the first time the vm boots, delete the rootdisk in the current dir
<clever> dejanr: you need to use users.users.X.initialPassword to set a pw
<clever> o1lo01ol1o: just nix-build the right iso attr of nixos/release.nix, but add --arg configuration ./configuration.nix
<clever> mudri: yeah
<clever> mudri: but it forces all playback to be mono
<clever> mudri: only thing close that ive played with, is the echo cancelation stuff in pulseaudio
<clever> it should probably be renamed to fetchAndUnpack, but have fun with the replace-all :P
<clever> so fetchzip will unpack, and hash the contents intead
<clever> causing the sha256 to change randomly
<clever> i think the main point, is that a lot of lazy websites, will dynamically generate the zip file on the fly, and mess up timestamps
<clever> but it still tries every unpacker it knows of