2019-12-15

<clever> and the return value can just be a string, delete the { helpers= and ;}
<clever> `helpers = import ./helpers.nix { inherit config lib; }` would work with your gist
<clever> `helpers = import ./helpers.nix { inherit (config.networking) enableIPv6; inherit lib; }`
<clever> oh, it needs a bool
<clever> `helpers = import ./helpers.nix { inherit iptables; }`
<clever> it may need an argument passed in, if you made it a function
<clever> `helpers = import ./helpers.nix`
<clever> probably
<clever> it just returns whatever expr is in the named file
<clever> > import ./foo.nix
<clever> lovesegfault: you likely want just dumb old import
<clever> lovesegfault: that assumes the file is a nixos module, which will set config and define options
<clever> possibly
<clever> and import it from both
<clever> lovesegfault: one option is to just have a dedicated nix file, `helpers.nix`
<clever> youll either need to move it somewhere more friendly, or just copy/paste
<clever> lovesegfault: its in a let block, so you cant
<clever> so helper now needs to be prepended to the dedicated nat service
<clever> and then helper vanishes
<clever> lovesegfault: but, if you disable the firewall, nat gets its own systemd service
<clever> lovesegfault: i suspect whats happening, is that the nat scripts, get inserted into the firewall scripts (with helper)
<clever> lovesegfault: understanding what changed to break it, can save a lot of time in fixing it
<clever> most other `git log` args also work
<clever> and `gitk branch1 branch2` to force both branches to be visible
<clever> you can also `gitk` to just view relative to the current rev
<clever> lovesegfault: then whack a `git bisect view` into that shell and oogle at it!
<clever> lovesegfault: install gitAndTools.gitFull instead of git, and youll get `gitk` and `git gui`
<clever> then you can see every change between good&bad
<clever> lovesegfault: you can also `git bisect view` if you have gitk installed
<clever> bisect can also be told to run nix-build directly, but ive never trusted that mode
<clever> lovesegfault: then just repeatedly nix-build the test, and `git bisect good` or `git bisect bad`
<clever> lovesegfault: then go to `job->overview` to see every build hydra has done for that, and find one where it worked, then run `git bisect good <rev>`
<clever> lovesegfault: start by running `git bisect bad` to tag the current one as bad
<clever> i think i did it!
<clever> :O!!!
<clever> [ 5.491912] Please append a correct "root=" boot option; here are the available partitions:
<clever> lovesegfault: oh, and also try doing a git bisect
<clever> lovesegfault: where is nat defined?
<clever> lovesegfault: its a bash function, defined inside a shell script
<clever> lovesegfault: its not a shell script either
<clever> lovesegfault: its not a binary
<clever> lovesegfault: one min
<clever> check the inputs tab
<clever> lovesegfault: including in this case?
<clever> and see if you can reproduce the fault locally
<clever> lovesegfault: ah, i would start by cloning that rev of nixpkgs, and doing `nix-build release.nix -A tests.nat.standalone.x86_64-linux`
<clever> lovesegfault: are you doing anything with nat?
<clever> lovesegfault: error: unit "nat" reached state "failed"
<clever> pie__: then nix can safely figure out what `config.c` is, and worry about a/b later
<clever> pie__: so if you do `config = mkIf condition { a=1; b=2; };` and something needs to read `config.c`, it will automatically translate into `config = { a = mkIf condition 1; b = mkIf condition 2; }`
<clever> pie__: i think that mkIf and mkMerge can be recursively pushed down
<clever> pie__: so you could add it to imports yourself
<clever> pie__: the vm thing simply adds a file to imports
<clever> nix-repl> config.nix.binaryCaches
<clever> [clever@system76:~/nixos-configs]$ nix repl '<nixpkgs/nixos>' --arg configuration ./nas.nix
<clever> pie__: or use nix repl directly
<clever> pie__: add the fancy one to $PATH
<clever> pie__: why?, you can run it from outside if you set the right flags
<clever> zeta_0: ive only built ghc under nix-build, never under nix-shell
<clever> jwaksbaum[m]: what error does it give, and what exactly did you set in configuration.nix?
<clever> pie__: ^^
<clever> system.copySystemConfiguration
<clever> If enabled, copies the NixOS configuration file (usually /etc/nixos/configuration.nix) and links it from the resulting system (getting to /run/current-system/configuration.nix). Note that only this single file is copied, even if it imports others.
<clever> src could also be another nix expression or derivation
<clever> jwaksbaum[m]: so i think you want boot.kernelPackages = pkgs.linuxPackages_custom { version = "123"; src = /path/to/source; configfile = ./config; };
<clever> jwaksbaum[m]: linuxPackages_custom is a function, which will take a version+src+configfile, and then wrap whatever linuxManualConfig made with that
<clever> 16448 recurseIntoAttrs (linuxPackagesFor (pkgs.linuxManualConfig {
<clever> 16447 linuxPackages_custom = { version, src, configfile, allowImportFromDerivation ? true }:
<clever> jwaksbaum[m]: you must use this function, to generate a linuxPackages set around a given kernel
<clever> 16428 linuxPackages_mptcp = linuxPackagesFor pkgs.linux_mptcp;

2019-12-14

<clever> duairc: just fill in the url of your hydra, and its public key, the `man nix-store` says how to make a keypair
<clever> duairc: line 52 tells hydra how to sign what it serves
<clever> duairc: yep, it already serves a binary cache over its http ui
<clever> duairc: builtins.fetchTarball can be used to bootstrap
<clever> duairc: ah, that should be fine
<clever> duairc: what did you give hydra as the nix expr?
<clever> duairc: run `sudo -u hydra -i` and then `hydra-eval-jobset <project> <jobset>` if you want to see cleaner logs
<clever> duairc: one sec
<clever> duairc: the same as if you just `git clone https://github.com/NixOS/nixpkgs-channels.git`
<clever> duairc: it downloads whatever the default branch is in github
<clever> duairc: what do you have set as the value under build inputs?
<clever> not sure
<clever> if things have changed, it will run an eval to see what
<clever> lovesegfault: once it has been a day since "last checked", it will check to see if anything on github has changed
<clever> lovesegfault: https://hydra.nixos.org/jobset/nixos/trunk-combined when does it say it was last checked?
<clever> rotaerk: just edit hardware-configuration.nix
<clever> rotaerk: no harm in removing it
<clever> juxiemaotu: yeah
<clever> juxiemaotu: nixos will automatically update nix.conf, based on certain nixos config flags
<clever> juxiemaotu: `nix show-config` lets you read the nix.conf file, while nixos-option lets you read any nixos config, some of the options also control nix.conf
<clever> juxiemaotu: `nix show-config`

2019-12-13

<clever> lol
<clever> o1lo01ol1o: weird that it was even doing it to begin with
<clever> samueldr: you ready to shave the yak? :D
<clever> samueldr: its called by down_write_killable, so mm/vmscan.c would have to be modified to use down_write_killable, and then fail in a clean manner if you kill it
<clever> kernel/locking/rwsem.c:EXPORT_SYMBOL(down_write_killable);
<clever> samueldr: there is a variant, that allows signals to kill it, and it wasnt used
<clever> kernel/locking/rwsem-xadd.c:EXPORT_SYMBOL(rwsem_down_write_failed_killable);
<clever> kernel/locking/rwsem-xadd.c:EXPORT_SYMBOL(rwsem_down_write_failed);
<clever> samueldr: let me check one more thing...
<clever> samueldr: so we could just go over every reference to shrinker_rwsem in this file, and consider what could make it not up after down
<clever> samueldr: the sem is also static, so only code in this one file can access it directly
<clever> samueldr: any sign of an OOPS in the logs?
<clever> samueldr: the offending thread could have gone off to do its own thing, or has entirely died
<clever> its a global semaphore
<clever> 170 static DECLARE_RWSEM(shrinker_rwsem);
<clever> which means, something else was already holding it
<clever> so it tried to grab this semaphore
<clever> down_write(&shrinker_rwsem);
<clever> samueldr: so gcc auto-inlined it
<clever> samueldr: which isnt inline, but it is static, which tells gcc the function cant be exported
<clever> samueldr: oh!, it calls prealloc_memcg_shrinker
<clever> samueldr: but i dont see how that can call down_write
<clever> samueldr: so, this is in the call stack
<clever> mm/vmscan.c:int prealloc_shrinker(struct shrinker *shrinker)
<clever> samueldr: ah wait, its not in old source, but it is in master
<clever> samueldr: cant find prealloc_shrinker in linux source...
<clever> quiet_laika[m]: guess its time to file a bug report!
<clever> quiet_laika[m]: try reading it with an editor, is a shell script? is the #! just missing?
<clever> quiet_laika[m]: sounds like the #! line is missing
<clever> quiet_laika[m]: `file result/bin/darwin-installer` ?
<clever> dirkx____: yep
<clever> dirkx____: your already cd'd into the source when buildPhase runs, you can confirm that by shoving `pwd ; ls -l ; exit 1` into preBuild
<clever> dirkx____: `preBuild = "cp ${./file.txt} file.txt";`
<clever> samueldr: that backtrace is weird, let me check the source...
<clever> samueldr: each one should have a pid listed near it, and one likely includes call_rwsem_down_write_failed
<clever> samueldr: `echo w > /proc/sysrq-trigger` and then check dmesg, any backtraces?
<clever> samueldr: sounds like its blocking in a semaphore, one min
<clever> samueldr: `ps a -o pid,wchan` is one way to list it
<clever> samueldr: what is the wchan?
<clever> but some people are paranoid, change it, and then things break
<clever> jared-w: yeah, the default works
<clever> jared-w: i dont think you have to do anything with builtin:local
<clever> jared-w: have you changes nix.allowedUsers any?
<clever> jared-w: and its just a check against localhost
<clever> in both cases, it uses stdin/stdout to talk to it, via the --serve rpc
<clever> jared-w: for non-local machines, it runs `ssh user@host nix-store --serve --write`, to talk to a remote daemon
<clever> jared-w: if the machine is detected as localhost, hydra will run `nix-store --serve --write` to talk to the local daemon
<clever> pingiun[m]: yeah, you have to add it to PATH yourself, optionally using buildEnv to merge many things together, then copy that, and add that to PATH
<clever> /bin/sed
<clever> pingiun[m]: after you chroot into that dir, you can run `/nix/store/hash-sed`
<clever> jared-w: this is what i use
<clever> { hostName = "localhost"; mandatoryFeatures = [ "local" ]; systems = [ "x86_64-linux" "i686-linux" ]; maxJobs = 4; }
<clever> jared-w: can you paste the value you have in buildMachines?
<clever> pingiun[m]: `nix copy --to local?root=$HOME/example /nix/store/hash-sed/`
<clever> jared-w: do you have localhost in any of the hydra or nix related config files?
<clever> lovesegfault: that already has user-selectable compression
<clever> lovesegfault: should be possible, have a look at the make-system-tarball file
<clever> lovesegfault: add --argstr system aarch64-linux, or use release.nix like in my example
<clever> lovesegfault: your doign an x86 build, not an aarch64 build
<clever> lovesegfault: i recently ran these, without any issues
<clever> [clever@system76:~]$ nix-build '<nixpkgs/nixos/release.nix>' -A sd_image.aarch64-linux -Q -o aarch64-image
<clever> [clever@system76:~]$ nix-build '<nixpkgs/nixos/release.nix>' -A sd_image_raspberrypi4.aarch64-linux -Q -o rpi4-image
<clever> lovesegfault: what error did it give?
<clever> CMCDragonkai: ive not used it before, not sure
<clever> CMCDragonkai: .serviceConfig.RuntimeDirectory ?
<clever> > builtins.baseNameOf "foo.img.bz2"
<clever> > lib.basename "foo.img.bz2"
<clever> lovesegfault: i think there is a lib.basename, but not sure what it will do there
<clever> monokrome: what is the exact error it gives?
<clever> monokrome: the firmware needs to be able to read the .efi file to boot, and the firmware usually doesnt know how to decrypt
<clever> lovesegfault: let pkgs = import ./. {}; in pkgs.callPackage ....
<clever> elvishjerricco: the default shell is likely nologin
<clever> elvishjerricco: `ssh -v` will show more status as it parses things
<clever> elvishjerricco: that would also effect you in the shell, if you do `ssh foo@bar`
<clever> elvishjerricco: what would `Match` match against?
<clever> elvishjerricco: that lets you pre-fill known_hosts
<clever> elvishjerricco: one minute
<clever> elvishjerricco: exactly
<clever> so if you `ssh foo`, it applies those 3 config entries when connecting to bar, but if you `ssh bar` it just ignores the cfg
<clever> and optionally, slap a `User foo` on as well
<clever> elvishjerricco: `IdentityFile /home/clever/.ssh/id_rsa_the_second` also changed where it looks for keys
<clever> elvishjerricco: `HostName bar` after that, causes it to instead ssh into far, instead of foo
<clever> elvishjerricco: `Host foo` tells ssh to run the following statements, if you `ssh foo`
<clever> but if you try to ssh into 1.2.3.4 directly, the config file does nothing
<clever> elvishjerricco: so if you try to ssh into snapshot-destination, the config file will forcibly change the hostname to 1.2.3.4
<clever> elvishjerricco: the ~/.ssh/config file can change the hostname of a host
<clever> elvishjerricco: ah, maybe ~/.ssh/config to setup which key to use when ssh'ing into a given host?
<clever> elvishjerricco: it likely runs as its own user? just `sudo -u foo -i` and `ssh-keygen` to drop some keys into its own ~/.ssh/id_rsa
<clever> CMCDragonkai: usually, the only thing you need is an ExecStart, and the rest can be ignored
<clever> CMCDragonkai: i would just ignore the supplied .service file
<clever> CMCDragonkai: i believe %i and %I work just fine in ExecStart
<clever> and bash's read can be told what sep to use
<clever> then you can concatStringSep "\n" [ "1 2" "3" ]
<clever> angerman: if you do `passAsFile = [ "foo" ]; foo = "anything";` then nix will set a $fooPath variable, and write "anything" to that path
<clever> angerman: thats where passAsFile and your own seperator could be used
<clever> angerman: but there is the new structured attrs stuff, which puts everything into json
<clever> angerman: i believe so
<clever> yep
<clever> gchristensen: nixos-rebuild still uses nix-env to manage the system profile

2019-12-12

<clever> o1lo01ol1o: /run/current-system and /nix/var/nix/profiles/system
<clever> o1lo01ol1o: check to see where system points, and what the logs say
<clever> o1lo01ol1o: and skipping the system profile entirely
<clever> o1lo01ol1o: something could be running /nix/store/cnsvrj5ms471f6mwq4r0xnf508cz1xza-nixos-system-unnamed-19.09.981.205691b7cbe/bin/switch-to-configuration directly
<clever> Dec 12 21:59:34 ec2-52-45-7-85.compute-1.amazonaws.com nixos[8323]: switching to system configuration /nix/store/cnsvrj5ms471f6mwq4r0xnf508cz1xza-nixos-system-unnamed-19.09.981.205691b7cbe
<clever> o1lo01ol1o: basically, yes, but it doesnt have to be at that path
<clever> o1lo01ol1o: but maybe there is something else, not the deploy script, that is screwing with things?
<clever> but those dont mess with nixos switch-to-configuration
<clever> o1lo01ol1o: is there some script or timer somewhere, that is re-running the wrong activate?
<clever> o1lo01ol1o: are you checking branches when gitlab pushes things? or is this trying to deploy every single branch to a single machine? gang-bang style? :P
<clever> o1lo01ol1o: that 2nd version likely didnt have a foo.service, so nixos stopped it
<clever> o1lo01ol1o: you deployed one version at 21:59:17, and then you deployed a different version at 21:59:34, just 17 seconds later
<clever> o1lo01ol1o: can you search your entire journal for this message?
<clever> 484 syslog(LOG_NOTICE, "finished switching to system configuration $out");
<clever> o1lo01ol1o: one min
<clever> o1lo01ol1o: its more likely that foo.service doesnt exist in the version you just deployed
<clever> o1lo01ol1o: the logs imply that the main process is exiting with code 0
<clever> o1lo01ol1o: when did foo.service become foo.target?
<clever> o1lo01ol1o: is the service self-forking?
<clever> o1lo01ol1o: /etc/systemd/system/foo.service
<clever> o1lo01ol1o: i just need the tail end, for the last run of the service
<clever> o1lo01ol1o: what are the contents of the .service file, and what is the full output from `journalctl -u foo.service` ?
<clever> try replugging? try another port?
<clever> sondr3: ls -l /nix/var/nix/profiles/system*/kernel
<clever> sondr3: one sec
<clever> betawaffle: mountpoint=legacy i think is only needed for things mounted by fileSystems., and specifically, things needed to boot (/ and /nix), you could potentially make everything else (even /home) normal zfs mounts, i think
<clever> roconnor: its building a new gcc that also runs under that new ligc
<clever> it doesnt really matter where on the disk you put it
<clever> when you set `boot.loader.grub.device = "/dev/sda"`, grub will look for a partition with that type, and use whatever offset the partition points to
<clever> thats the uuid type for the bios boot partition
<clever> exactly
<clever> if you `hexdump -C $DISK | head -n30` you should see something funny, if it worked right
<clever> the bios boot partition can be anywhere on the disk, it just needs a special type code
<clever> no clue what thats doing
<clever> betawaffle: and to make legacy boot work on gpt, you also need a bios boot partition, 1mb, not mounted, not formatted
<clever> betawaffle: that will require fat32 on /boot, so the bios can read the .efi files
<clever> betawaffle: if you enable efi support, and also set boot.loader.grub.device = "/dev/sda"; then it will do both an efi and legacy install at the same time
<clever> betawaffle: you can even configure nixos to boot with both legacy and efi at the same time
<clever> betawaffle: yep
<clever> wucke13_: journaling, i dont trust fat32 as far as corruption and improper shutdowns
<clever> grub has poor zfs support, and just barely works
<clever> betawaffle: for zfs, i would recomend an ext4 fs for /boot/
<clever> betawaffle: if you have an ext4 /, then /boot can just be a directory within the / fs
<clever> betawaffle: depends on what fs you use as / also
<clever> betawaffle: several images like the livecd will just use a blank tmpfs for /, giving similar behaviour
<clever> betawaffle: NIXOS_LUSTRATE is a flag for the initrd, to just rename everything in / on bootup
<clever> earldouglas: looks like the fhs-env script crashed, not sure why
<clever> earldouglas: what about `strace -f -e execve android-studio` ?
<clever> earldouglas: what does `file` report for the binary your running?
<clever> roconnor: git clone nixpkgs, then edit the above file and change the version and sha256
<clever> > pkgs.glibc.meta.position
<clever> roconnor: ah, then you may want to just edit nixpkgs
<clever> roconnor: simplest is to just find a version of nixpkgs that is that old
<clever> thomasho1eyman: ive done basically that in the past, to just jam a ghcid into the existing .env shell
<clever> thomasho1eyman: .env.overrideAttrs (old: { buildInputs = [ ghcid ] + old.buildInputs; })
<clever> rizary_: the default.nix returns a set, containing all of those attrs
<clever> which then makes it safe for you to ditch the outer libtorch-ffi-src. via inherit
<clever> but callPackages moves it, letting you do libtorch-ffi-src.libtorch-ffi-src.override
<clever> with callPackage, you would have had to do (libtorch-ffi-src.override {...}).libtorch-ffi-src
<clever> the difference between callPackage and callPackages, is where .override lands
<clever> rizary_: and you needed to do libtorch-ffi-src.libtorch-ffi-src
<clever> rizary_: so when you did `libtorch-ffi-src = pkgs.callPackage (hackGet deps/hasktorch) {};`, that means libtorch-ffi-src is a set, not a single package
<clever> rizary_: neither, its because it returns a set of packages
<clever> rizary_: callPackages deals with the fact that it returns a set of many packages, and then inherit lets you pull a few ones out, at your choosing
<clever> rizary_: inherit (pkgs.callPackages (hackGet deps/hasktorch) {}) libtorch-ffi-src;
<clever> rizary_: and for the way your currently loading it, you want callPackages, with an s
<clever> rizary_: its a set, so you want `(import (hackGet deps/hasktorch)).libtorch-ffi_cpu``
<clever> rizary_: what does `import (hackGet deps/hasktorch)` return?
<clever> rizary_: now try `import (hackGet deps/hasktorch)` ?
<clever> rizary_: in this case, `nix repl '<nixpkgs>'` and then just eval `hackGet = p: self.fetchFromGitHub (builtins.fromJSON (builtins.readFile (p + "/github.json")))` and `hackGet deps/hasktorch`
<clever> rizary_: what do you get if you eval `hackGet deps/hasktorch` in a `nix repl` ?
<clever> ah, callPackage will import for you
<clever> rizary_: you must then import that, to get the contents of its default.nix
<clever> rizary_: fetchFromGitHub returns a derivation, which is both a set and a string (the path to the thing)
<clever> and that led to a driver involved in phone charging, lol
<clever> i cant remember which tool, but it gave a backtrace, with driver names and addresses
<clever> that is the only time i have ever been able to diagnose and fix a bluescreen
<clever> EdLin: *boom*, bluescreen, instantly
<clever> EdLin: then one day when my dad was cleaning up, he moved it from the other side of the room, and i had to plug it back in, but i omitted the active usb extension (a 1 port hub) since i didnt really need it on the other side of the room anymore
<clever> EdLin: so i just left it plugged in 24/7, lol
<clever> EdLin: but, the firmware was fairly flexible, and claimed to also be a usb mouse, which eliminated the bugs
<clever> EdLin: i was also using a teensy uC at the time, programmed to act as a 2 button usb keyboard, so i could pause and rewind vlc easily
<clever> i was using synergy to forward the mouse from linux
<clever> so, how am i rolling the wheel, without a wheel? :P
<clever> BUT!, it only happens if you dont have any mouse plugged in when you launch the game
<clever> making the menu's imposible to navigate
<clever> in certain games (like skyrim), if you roll the mouse wheel, it just scrolls infinitely
<clever> notgne2: that reminds me of weird infinite scroll issues i had on windows
<clever> so it "runs" perfectly, but your aim is thrown off every time you try to interact :P
<clever> and the game is heavily mouse-look + click based
<clever> stationeers used to work perfectly, but they updated the unity engine, and now the mouse goes nuts every time you left click
<clever> space engineers and elite dangerous just fail for weird or unknown reasons
<clever> elvishjerricco: ah, that would likely prevent the init issues i had also
<clever> EdLin: just pkgs.steam in systemPackages
<clever> and 1 which used to work, but has since broken (due to an update)
<clever> i can only think of 3 games that dont work at all
<clever> steam and proton suppot have been great on nixos, so i havent had as big of a need to redo all of that
<clever> notgne2: but that also fires a lot later into the boot process, and would have the init issues i had, requiring some way to reboot the gpu
<clever> and on the host side, you bind one to the gpu, so nothing else can use it
<clever> EdLin: i cant remember exactly which one, but one is used on the host, and the other on the guest, and they talk over a xen channel, to agree on what to forward and how
<clever> [root@amd-nixos:~]# modinfo xen-pcifront