<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>
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>
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>
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>
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>
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: 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>
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_: 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