2020-10-20

<clever> you may want to force a bootloader reinstall
<clever> did you just copy the entire disk?
<clever> and was sda1 mounted to /mnt/boot when you did nixos-install?
<clever> __red__: what fs type is / ?
<clever> __red__: what does `mount` say about /boot/ ?
<clever> __red__: is /boot correctly mounted?
<clever> pickfire: probably
<clever> ,tell Henson like this
<clever> Henson: but you never spoke infront of {^_^}, so it didnt know you had returned!
<clever> Henson: you asked about the kexec stuff, and DC'd, so i had {^_^} pass along the msg
<clever> pickfire: its a symlink to the latest profile-???-link in the same dir
<clever> so you can just enable the xserver
<clever> the nixos tests take a configuration.nix
<clever> what about the hello package?
<clever> pickfire: is it just nix-shell, or is the package broken in other ways?
<clever> it was 522 about 30mins ago
<clever> the bot does that randomly, lol
<clever> it should also be in the docs
<clever> you can increse that with log-lines in either nix.conf or --option
<clever> [root@amd-nixos:~]# nix show-config | grep log-lines
<clever> log-lines = 10
<clever> it only oom's if you use -i without -A
<clever> get some swap?
<clever> pickfire: you would have to delete the profile to be able to go back
<clever> pickfire: i'm guessing that using `nix profile` once is a permanent upgrade, and you cant go back to `nix-env`
<clever> pickfire: nixpkgs.sakura

2020-10-19

<clever> tobiasBora: you replaced foo with /nix/store/hash-foo, instead of /nix/store/hash-foo/bin/foo
<clever> so it will fail to actually run anything
<clever> also, your patching a directory into the path for the binaries
<clever> but you can also combine several scripts into one runCommand
<clever> tobiasBora: you +x it after you tried to patch, so it never patches
<clever> tobiasBora: patchShebangs only acts on files that are +x'd, line 76 shows it doing that search
<clever> tobiasBora: try throwing a `set -x` in and then look at the debug bash spews out
<clever> tobiasBora: did you include patchShebangs in the shell code? i dont see it in the pastebin
<clever> tobiasBora: and what are the contents of k2pdfopt_cut_and_crop.sh ?
<clever> tobiasBora: you have to run substiteAll on the script for @foo@ to get replaced
<clever> __red__: if you check the email on one of his recent commits (https://github.com/danielfullmer/robotnix/commit/b7215c1a17c3f034c93c1d3f8305e653cb4cd2e6.patch) youll see that it matches up pretty closely with a danielrf[m] in irc
<clever> then you can fixup $PATH, and source the original
<clever> source will ignore the #!
<clever> tobiasBora: yeah, at that point you would want to source the original script, or use wrapProgram
<clever> you can also run `patchShebangs $out/bin/` to force it into patching
<clever> tobiasBora: if you use something like `#!/usr/bin/env bash`, then the patchShebangs function will replace it with $(which bash) during the fixupPhase
<clever> tobiasBora: and this shell will be correct even when cross-compiling
<clever> > "#!${pkgs.runtimeShell}"
<clever> tobiasBora: nix auto-detects dependencies based on what strings you use
<clever> typetetris: i would expect it to affect all, but maybe your using a different version of nix-shell and its fixed in some?
<clever> tobiasBora: *doh*
<clever> typetetris: oh, i sent the answer to tobiasBora by accident! check up about 30mins
<clever> and throw a chmod +x in
<clever> tobiasBora: runCommand "name" {} "mkdir -p $out/bin ; cp ${./input.sh} $out/bin/output"
<clever> tobiasBora: you either want builtins.readFile or runCommand
<clever> tobiasBora: and that .sh file wasnt +x'd, so permission denied
<clever> tobiasBora: so the final shell script was "#!/bin/sh\n/nix/store/hash-k2pdfopt_cut_and_crop.sh"
<clever> tobiasBora: writeShellScriptBin takes 2 strings, not a string and a path
<clever> tobiasBora: what is the exact expression and exact error?
<clever> tobiasBora: you can probably use taskset to revert it, once in the shell
<clever> tobiasBora: and nix-shell doesnt undo that (a bug in nix-shell)
<clever> tobiasBora: i believe nix pinns itself to a random core during the eval phase
<clever> Nix_Installer: or the cable is damaged, or loose
<clever> Nix_Installer: your drive is failing, and corrupting random files, fix the drive first

2020-10-18

<clever> then something is wrong with either the drive or the cable
<clever> Nix_Installer: any errors at the end?
<clever> Nix_Installer: does dmesg say anything?
<clever> Nix_Installer: does `lsblk` agree that sda1 is 1.8tb?
<clever> Nix_Installer: does `mount` say anything on sda is mounted?
<clever> thats sda, not sda1
<clever> Nix_Installer: and `fdisk -l /dev/sda` says sda1 is how big?
<clever> but thats likely already automated
<clever> Nix_Installer: then you should be using 4kb alignment for the partitions, and 4kb block sie (a bigger multiple) for ext4 block sizes
<clever> and these 2 ones dont accept any cfg
<clever> pbogdan: ah, different toJSON, that throws out one arg, and takes another!
<clever> 127 toJSON = {}: builtins.toJSON;
<clever> pbogdan: what? how does that even work, from the code i pasted above??
<clever> Raito_Bezarius: try builtins.toJSON instead
<clever> Raito_Bezarius: how does it fail?
<clever> Raito_Bezarius: all valid json, is also valid yaml
<clever> Raito_Bezarius: and the comment above that line, reminds us that toJSON will work perfectly as well
<clever> i dont see how toYAML would ever work
<clever> without `{ ... }@args`, it will never accept any argument
<clever> thats very weird
<clever> 135 toYAML = {}@args: toJSON args;
<clever> Raito_Bezarius: nix run -f '<nixpkgs>' something
<clever> tokudan: ah, thatll do it
<clever> bqv: you can run nix-store --delete on the output, then you can re-run it
<clever> tokudan: not sure then, ive got nixpkgs rev e2bb73ce5f7 on my laptop, from nixos-unstable, and its running virtualbox just fine
<clever> tokudan: what does `which VirtualBox` return?
<clever> tokudan: are you pinning anything to old versions?
<clever> tokudan: what about root's `nix-env -q` ?
<clever> tokudan: you must either remove (or upgrade) every QT based program in `nix-env -q`
<clever> tokudan: that happens if you have QT programs in nix-env, and you upgrade nixos
<clever> evanjs: in other news, i can now reflash a pi4 over usb, https://github.com/librerpi/rpi-tools/tree/master/webusbboot
<clever> it doesnt follow master, so it will be fairly behind
<clever> evanjs: with an rpi4 helping out on occasion (but its currently unplugged)
<clever> evanjs: i was just using qemu-user-arm to do "native" arm builds on my laptop
<clever> if neededForBoot is missing, it will do the bind mount much later in the boot process

2020-10-17

<clever> ,escape ${asd}
<clever> ,escape'' ${asd}
<clever> yep
<clever> but fcitx-mozc focred clang
<clever> on linux, the default is gcc
<clever> but if you want to builds things, you have to fetch the compilers again
<clever> it deletes anything your not currently using at runtime
<clever> probably because the ollect-garbage cmd ate everything it needs to do even basic tasks
<clever> likely
<clever> so it needs clang to build it
<clever> then you dont already have it installed
<clever> 2020-10-17 14:12:24 < pickfire> I already have fcitx-mosc installed IIRC.
<clever> pastebin that list
<clever> yeah
<clever> before that
<clever> the part where it tells you what its going to build
<clever> before the failure, what is the output?
<clever> what did `nixos-rebuild test` output? that tells you the answer
<clever> 2020-10-17 14:12:22 < clever> 2020-10-17 13:56:38 < clever> what did it output?
<clever> then that doesnt depend on clang at runtime
<clever> does that list clang?
<clever> oops, `nix-store -qR /nix/store/k4ih813wnrpc2jjgh604isksl2n20512-fcitx-mozc-2.23.2815.102`
<clever> and now, `nix-store -qR k4ih813wnrpc2jjgh604isksl2n20512-fcitx-mozc-2.23.2815.102`
<clever> anything that doesnt end in .drv?
<clever> to find fcitx-mosc
<clever> change it to `ls /nix/store | grep fcitx-mosc`
<clever> try `git gc` i think it was?
<clever> change the grep to look for a different thing
<clever> 2020-10-17 13:58:02 < clever> pickfire: ls /nix/store | grep clang
<clever> pickfire: you can just look in /nix/store
<clever> what is the storepath to it?
<clever> 2020-10-17 13:56:38 < clever> what did it output?
<clever> 2020-10-17 13:56:35 < clever> what command did you run to start this whole problem?
<clever> but is fcitx-mozc needing to build?
<clever> which is a dep of fcitx-with-plugins
<clever> fcitx-mozc is the actual thing depending on clang
<clever> because the -q --tree said clang...patch
<clever> oh, thats only the clang patch
<clever> > db.meta.description
<clever> pickfire: yep, db depends on clang
<clever> pickfire: `nix show-derivation /nix/store/4yvbhk5viq065nvm3sbhg7qsyjgp70br-db-4.8.30.drv` ?
<clever> but "db" is also in that path
<clever> yeah, it is pointing to linux-pam
<clever> gist.github.com is what i tend to use
<clever> pickfire: that works
<clever> pastebin the area between pam and clang?
<clever> and use /clang to search
<clever> nix-store -q -tree ${something} | less
<clever> then searech for clang, and follow the line upwards, what does the line hit?
<clever> nix-store -q -tree ${something}
<clever> nix-store -qR ${something} | grep clang
<clever> pickfire: nix-instantiate /home/pickfire/nixpkgs/nixos -A system
<clever> pickfire: nix-store -q --roots /nix/store/p64np7bz48459c8i0gzc0mksjj33kvxf-clang-7.1.0
<clever> pickfire: pastebin?
<clever> pickfire: ls /nix/store | grep clang
<clever> pickfire: `nix-store -qR /run/current-system | grep clang` ?
<clever> yes
<clever> what did it output?
<clever> what command did you run to start this whole problem?
<clever> 2020-10-17 13:43:28 < clever> pickfire: and nix-store -q --roots to find out what is the GC root
<clever> you asked it, why does clang depend on ""
<clever> why does X depend on Y
<clever> b: you must give it 2 store paths
<clever> a: the sudo is pointless
<clever> what did you run, exactly?
<clever> and with the right hash
<clever> pickfire: you have to give it the path of the clang already on your machine
<clever> nix why-depends /nix/store/foo /nix/store/hash-clang
<clever> pickfire: i find its best used on storepaths
<clever> if 2 files have the same contents, they wind up sharing the same blocks on disk, via that hardlink
<clever> pickfire: because --optimize will hardlink every single file to /nix/store/.links/${hash}
<clever> pickfire: try `nix-store --optimize` ?
<clever> and you want to limit how much you delete at once
<clever> because the act of deleting files, needs space
<clever> you also need to use `--max-freed 1` as well when low on space
<clever> i have seen several people -d, then realize it was they need to undo, and cant because they basically bricked the machine
<clever> try without -d first
<clever> you generally dont want to use -d, that will ruin your ability to undo things
<clever> one non-nix file
<clever> pickfire: manually delete one file, and try `nix-collect-garbage --max-freed 1`
<clever> why-depends then gives the path from a root to clang
<clever> pickfire: and nix-store -q --roots to find out what is the GC root
<clever> tobiasBora: dontPatchShebangs = true?
<clever> tobiasBora: dontPatchELF = true; will disable that
<clever> 5 fixupOutputHooks+=('if [ -z "${dontPatchELF-}" ]; then patchELF "$prefix"; fi')
<clever> pkgs/development/tools/misc/patchelf/setup-hook.sh: echo "shrinking $i"
<clever> whald: if you bisect hydra, you could narrow down what exactly it is
<clever> whald: probably the hydra version then
<clever> whald: hydra-eval-jobs doesnt rely on any state or DB, so you can just freely run it with those args, from any build of hydra
<clever> whald: i'm not sure, but you can nix-build different versions of hydra, and re-run the new hydra-eval-jobs on each build, to see when it works and doesnt
<clever> whald: compare the example/hello.nix in /nix/store/n093kdbbiyw0ws47979c7h7aqkl1w5gw-source to the checkout?
<clever> whald: change the `-I hydra=...` to a local copy, and then delete the `{ ... }:` line, any difference?
<clever> whald: try adding the --arg's back in one at a time, singlequote the chuck of nix for each one
<clever> whald: try manually running: /nix/store/gd08h77dxv04r0068b4nc6i1s6yahzrj-hydra-2020-09-02/bin/hydra-eval-jobs '<hydra/examples/hello.nix>' -I nixpkgs=/nix/store/z01h57s6qr3m8x7ihqr0m3mqdwg6ij71-source -I hydra=/nix/store/n093kdbbiyw0ws47979c7h7aqkl1w5gw-source
<clever> whald: yep, everything there looks good, does gdb show the args that hydra-eval-jobs was ran with?
<clever> lordcirth: higher performance overhead
<clever> but it guessed wrong
<clever> lordcirth: dynamically, based on how much it expects to use
<clever> and it didnt allocate enough
<clever> the problem is more that the code allocates a fixed-size array, for the key/value pairs in a set
<clever> whald: can you screenshot the hydra jobset config, or link the hydra itself?
<clever> this is one of the lines from the backtrace
<clever> lordcirth: slots in an array
<clever> and then something didnt fit
<clever> whald: the specific error, is because nix internally needs to allocate enough room for every key in a set
<clever> whald: and how is the jobset configured?
<clever> whald: can you also link/paste the release.nix file?
<clever> whald: you can do things like `coredumpctl gdb <pid>` to open gdb on any dump
<clever> whald: you would have to check `coredumpctl` on the server
<clever> whald: what does the backtrace say?
<clever> also, you want to instead use runCommand "remarkable-toolchain-sdk" { inherit src; } ''shellcode'';
<clever> so thats src = { src = fetchurl ...; };
<clever> Orbstheorem: you gave it a set, containing a src key
<clever> Orbstheorem: extractToolchainFromScript takes one argument, the entire arg is put into src
<clever> Orbstheorem: oh, i see the problem
<clever> Orbstheorem: and what does builtins.fetchurl return, when ran in `nix repl`?
<clever> Orbstheorem: does the error say what line its on? does --show-trace say something useful?
<clever> Orbstheorem: can you paste your code?
<clever> Orbstheorem: fetchurl is already a derivation
<clever> Orbstheorem: just assign it to the src attr
<clever> boogiewoogie[m]: look at linuxPackagesFor in all-packages.nix, youll probably want boot.extraModulePackages = [ (config.boot.kernelPackages.callPackage ./your-module.nix {}) ];
<clever> boogiewoogie[m]: yeah

2020-10-16

<clever> jasom: buildEnv

2020-10-15

<clever> gluonix: genericBuild will then cd into $sourceRoot, and continue the build
<clever> gluonix: the unpackPhase will unpack $src, then set $sourceRoot to point to the directory it just made
<clever> clefru_mm: builtins.fetchGit doesnt need a hash, its different from pkgs.fetchgit
<clever> clefru_mm: there is also builtins.fetchgit
<clever> clefru_mm: but thats going to still rebuild every time any file changes, not just files git is tracking
<clever> clefru_mm: pkgs.runCommand "name" { buildInputs = [ git ]; } "git clone ${./.} $out" would do the same thing
<clever> src = lib.cleanSource ./.; is one way to remove the extra stuff and make the hash more stable
<clever> but often, you added a result symlink to the dir, and now the hash differs
<clever> clefru_mm: and if the hash is the same, it wont rebuild
<clever> clefru_mm: when you do `src = ./foobar;` nix will copy the entire directory at eval time, and hash that copy
<clever> exactly
<clever> codygman__: run the `ghc-pkg list` inside that ghc
<clever> superherointj: its implemented in plain nix, rather then c++
<clever> 225 mod = base: int: base - (int * (builtins.div base int));
<clever> > lib.mod 14 5
<clever> DigitalKiwi: if you can get a .drv out of that with `nix-store --query --deriver`, then you can nix-diff your way to recreating the cfg
<clever> pumpy: no idea whats going on then
<clever> pumpy: if you do the same thing without making a snapshot, does it have any difference?
<clever> and only one guest from that disk at a time, right?
<clever> are you booting the guest from the original or the snapshot?
<clever> when does the fsck get ran? on bootup?
<clever> that should just work without any issues
<clever> pumpy: and you never mount /dev/zroot/nix on the host, correct?
<clever> pumpy: on the host side, the device backing vda
<clever> pumpy: and then the VM is configured to use /dev/zroot/nix ?
<clever> pumpy: how is that configured on the host?
<clever> pumpy: how is the VM giving the guest access to the volume?
<clever> pumpy: how is the guest accessing the zvol?
<clever> pumpy: that shouldnt cause any visible effect in the guest
<clever> pumpy: what zfs command did you run?
<clever> ah, if it builds then your already solved
<clever> DigitalKiwi: review the --show-trace line by line and look for any potential cycles
<clever> DigitalKiwi: youll need to be careful, because what if self.smallcheck_1_2_0 depends on random_1_2_0?
<clever> ah, modifying an existing overlay
<clever> DigitalKiwi: are you passing the file in the above gist to overrideScope?
<clever> DigitalKiwi: super is the previous value, so you can avoid infinite recursion
<clever> DigitalKiwi: self is the final value after the overlay has been applied
<clever> DigitalKiwi: overrideScope inserts an overlay onto a scope, mutating many packages
<clever> DigitalKiwi: overrideCabal acts on the args passed to the haskell mkDerivation function
<clever> DigitalKiwi: .override acts on the args callPackage passed into the package
<clever> and just exports every var nix-build would have exported
<clever> nix-shell can take any derivation
<clever> you can usually just jump right to running make when resuming
<clever> zecnate: but if you nix-build --keep-failed, then nix-shell, you can cd into that tempdir, and resume the build
<clever> zecnate: the sandbox isnt active, so it can see things it shouldnt see
<clever> ,tell Henson sure!

2020-10-14

<clever> but now its hash-source and hash-source, and it finds the old copy more easily
<clever> so it would try to download package-2, and then discover the hash is wrong
<clever> but it re-checking was more of an accidental feature, because /nix/store/hash-package-1 wont make a search for /nix/store/hash-package-2 happy
<clever> pie_: usually, if the version# changes, the contents definitely changed
<clever> aswanson: but the name has since been set to "source" for most things, breaking that
<clever> aswanson: previously, the version was included in the name, so the name+hash would have differed
<clever> aswanson: if you claim the hash and name are the same, then nix will trust you, and reuse the old thing by that name&hash
<clever> let blocks are recursive, sets arent
<clever> pkgs.newScope in my simple-test.nix example
<clever> pie_: thats the newScope function, from the parent scope
<clever> pie_: so you can put a scope within a scope
<clever> pie_: and makeScope will create another newScope within that new scope
<clever> so when you run the new callPackage on `{ a }: ...`, it will look for extra.a first, then splicedPackagesWithXorg.a
<clever> pie_: you pass it a set, and it will create a custom callPackage, that searches an extra place
<clever> 132 newScope = extra: lib.callPackageWith (splicedPackagesWithXorg // extra);
<clever> nix-repl> pkgs.newScope
<clever> «lambda @ /nix/store/1v1jczwm2d4wff3yq5j3zrknifpk8m77-nixos-21.03pre243434.e0759a49733/nixos/pkgs/top-level/splice.nix:132:14»
<clever> packages = with pkgs.lib; self: {
<clever> self = pkgs.lib.makeScope pkgs.newScope packages;
<clever> yep
<clever> it takes an overlay as input, and re-does the fixpoint
<clever> that allows mutating the package set
<clever> pie_: newScope adds an .overrideScope for you
<clever> then youll just need to configure it the old way
<clever> jasom: with home-manager, maybe
<clever> jasom: programs = { gnupg.agent = { pinentryFlavor = "gtk2";
<clever> `nix-env -i $(nix-build '<nixpkgs>' -A pinentry-qt)` would trick it into installing -qt instead
<clever> jasom: and nix-env prefers installing the .out of things
<clever> jasom: because pinentry-qt is an alias to pinentry.qt
<clever> ugubok: did you try adding glib to the buildInputs?
<clever> gluonix: if you use plain stdenv.mkDerivation it will work a lot better, without a lot of that code
<clever> gluonix: make, autoconf, and gcc are in the stdenv by default, but stdenvNoCC forces them to not be there
<clever> gluonix: line 24 of the Dockerfile, that is going to copy things weirdly and break a lot of stuff, you need to give it a derivation not a path