2019-12-11

<clever> hexa-: both the initrd and kernel need to be accessible to open the prompt
<clever> fresheyeball: pytorch, the stdenv will get .dev for you
<clever> another factor, is if you have seperate /boot and /boot/efi's
<clever> fresheyeball: the postUnpack was for fuzen
<clever> fuzen: ^^
<clever> fresheyeball: postUnpack = "sourceRoot+=/socket-io; echo source root reset to $sourceRoot";
<clever> fresheyeball: the installPhase for pytorch may not copy the right files
<clever> EdLin: `rm result` not `rm result/`
<clever> which gets worse if i cross a cabal file boundary
<clever> main problem i run into, is when i'm editing a library, and want to repl an executable
<clever> and this lets you run ghcid against cabal projects
<clever> ghcid -c "runhaskell Setup.hs repl"
<clever> so you could just point it towards a testcase, and let it rip
<clever> ghcid can also be configured to run an `IO` thing after all warnings are gone
<clever> fresheyeball: nope
<clever> zeta_0: but youcompleteme in vim will auto-complete any "word" present in any open buffer, and i usually have those open for cross-referencing, or they are already used nearby
<clever> zeta_0: about the only thing my workflow is missing (vim + ghcid) is context aware auto-completion
<clever> CMCDragonkai: if you name it shell.nix, then you can just `nix-shell`
<clever> CMCDragonkai: only way to make it shorter, is to put that string into a .nix file, and run `nix-shell thatfile.nix`
<clever> with ghcid, you dont really need an IDE
<clever> so you can see the most recent warnings/errors
<clever> a program that runs ghci, and then does :r every time you modify a file
<clever> you give it a string, it runs the string, end of story, lol
<clever> zeta_0: system was a typo
<clever> nothing stops you from doing normal haskell things inside the haskell code, including using things like turtle or systemm
<clever> zeta_0: `-p ghc` auto-generates: with import <nixpkgs> {}; stdenv.mkDerivation { name = "something"; buildInputs = [ ghc ]; }
<clever> oh, `-ff` instead of `-f` makes it a bit more readable
<clever> then read the logfiles
<clever> then try using eshell, and exit
<clever> zeta_0: `strace -o logfiles -f -e execve emacs something.hs`
<clever> zeta_0: try straceing emacs, to see what it ran nix-shell with
<clever> zeta_0: youll need to investigate what eshell is doing differently to fail
<clever> zeta_0: try testing with a plain nix-shell first
<clever> in this case, the macho library was so ancient, it didnt compile with modern ghc, and was missing a couple features
<clever> machotool also includes an example of how to override libraries
<clever> zeta_0: https://github.com/cleverca22/machotool/blob/master/default.nix in this one, i dont have a shell.nix, but i am using cabal2nix, so it works via `nix-shell -A machotool.env`
<clever> zeta_0: in this project, im just using ghcWithPackages, so the shell.nix is just refering to the default.nix (indirectly)
<clever> and it will load whatever the shell.nix said to load
<clever> zeta_0: if you create a shell.nix file, you can just run `nix-shell` with no args
<clever> zeta_0: that was giving you a ghc with no modules at all
<clever> zeta_0: can you copy/paste everything the terminal is showing, to a pastebin?
<clever> zeta_0: correct, brick will only be visible when inside that shell
<clever> zeta_0: what does `which ghc` return inside that shell?
<clever> zeta_0: what args did you give to nix-shell?
<clever> zeta_0: 2 months later, when your on a different machine (or your home.nix has evolved), you wont be able to build that project anymore
<clever> i make a shell.nix for each project, that pulls in the right libraries for that project
<clever> zeta_0: if you install ghc with home-manager, you will run into problems when you need a different ghc next week
<clever> zeta_0: and i would recomend using a shell.nix and default.nix to provide that, so you dont get ghc's mixed up between projects
<clever> zeta_0: you must use the ghc that comes from `haskellPackages.ghcWithPackages (ps: [ ps.brick ])`
<clever> zeta_0: haskell modules are only ever visible if you correctly use ghcWithPackages
<clever> fresheyeball: is the sha256 correct?
<clever> ah, so it could be that pytorch is just old
<clever> fresheyeball: that might be your problem
<clever> fresheyeball: is the missing header at result-dev/include/c10/cuda/impl/cuda_cmake_macros.h ?
<clever> fresheyeball: now look in result-dev/include/
<clever> fresheyeball: what happens if you try to build pytorch.dev?
<clever> fresheyeball: thats not how split outputs work
<clever> fresheyeball: is it split output? does it have a .dev output?
<clever> fresheyeball: and if you nix-build pytorch, does it have that file in its include dir?

2019-12-10

<clever> o1lo01ol1o: sounds like gitlab isnt building the right thing
<clever> fresheyeball: ls -l result/include/
<clever> fresheyeball: use nix-build to find the $out of cuda, and then ls it
<clever> fresheyeball: is that directly in the $out/include of cuda?
<clever> fuzen: id unpack the image, and use patchelf
<clever> haskell makes it much simpler to just jam 2 unrelated programs into one binary
<clever> ah yeah, rewriting in rust would be tricky there, lol
<clever> chromium alone is a 200mb executable
<clever> betawaffle: have fun with upgrading! lol
<clever> betawaffle: haskell-init generates a single 2mb executable, which runs as init in the initrd, thats it
<clever> betawaffle: not-os uses a heavily stripped down nixos config, and generates a ~40mb squashfs for the nix store
<clever> betawaffle: there is another one , that is even more tiny
<clever> gchristensen: have you tried `rmmod xhci_hcd` to see if that also helps?
<clever> jared-w: and he's gone!
<clever> magthe: pkgs.haskellPackages
<clever> rendeko[m]: there is also the users.users section of `man configuration.nix` and https://nixos.org/nixos/options.html#users.users
<clever> rendeko[m]: the users.users section of the nixos manual
<clever> rendeko[m]: adding isNormalUser = true; should fix it
<clever> rendeko[m]: ah, so nixos updated the groups, and nothing else was defined, so nixos also took over and used the default home and shell
<clever> rendeko[m]: do you have `isNormalUser = true;` set for that user?
<clever> rendeko[m]: your local user has no home or shell
<clever> rendeko[m]: `grep $USER /etc/passwd` ?
<clever> rendeko[m]: what does `env | grep empty --color` reveal?
<clever> rendeko[m]: the issue is on the local machine, not the remote machine
<clever> rendeko[m]: can you pastebin the output from `ssh -vv chelsea@IPADDR` ?
<clever> rendeko[m]: looks fine, what ssh command did you run?
<clever> fresheyeball: you probably have to add which to the nativeBuildInputs
<clever> rendeko[m]: check to see what /etc/passwd says about that user
<clever> rendeko[m]: sounds like the user your ssh'ing into doesnt have a home set
<clever> o1lo01ol1o: the result symlink will point to it, nix-copy-closure and nix-env --set are also being ran on that
<clever> o1lo01ol1o: what is the hash for the non.drv version?
<clever> o1lo01ol1o: what path did gitlab build?
<clever> it will only see the shell script and wont think its a python thing
<clever> yeah
<clever> which then runs the python script
<clever> youll need to create a derivation that only has a $out/bin/tahoe-lafs shell-script, using writeShellScriptBin
<clever> nixops also does that, and causes some issues
<clever> exarkun: the setup hooks add it and all of its propagated stuff to PYTHONPATH
<clever> exarkun: line 7 says python2Packages
<clever> exarkun: what is the expression you used?
<clever> o1lo01ol1o: that shouldnt be a factor
<clever> o1lo01ol1o: youll need to modify deploy-server.nix, and add a .system at the right spot, then see what happens when you deploy
<clever> o1lo01ol1o: that would likely be part of your problem, try -A server.system ?
<clever> o1lo01ol1o: if you eval it in nix repl, what do you see?
<clever> o1lo01ol1o: what is that expr doing? does it return a single derivation or a set?
<clever> o1lo01ol1o: and what is server set to in the expr?
<clever> o1lo01ol1o: what args do you pass to nix-build?
<clever> o1lo01ol1o: it sounds like its just running the wrong build
<clever> o1lo01ol1o: ah yeah, dang
<clever> o1lo01ol1o: but you could still evaluate it and compute the $out, using nix-instantiate
<clever> o1lo01ol1o: try just building it again with nix-build and check its path
<clever> o1lo01ol1o: is result from the latest build of that machine?
<clever> o1lo01ol1o: does `result/etc/systemd/system/firewall.service` open 443?
<clever> o1lo01ol1o: compare the path of your latest build with `ls -l /run/current-system`, do they match?
<clever> o1lo01ol1o: does the /nix/store/75bb8q3idi8swamrss36cy2z5wvkc8ym-firewall-start/bin/firewall-start file open port 443?
<clever> betawaffle: space, enter works on irssi too
<clever>
<clever> o1lo01ol1o: grep ExecStart /run/current-system/etc/systemd/system/firewall.service ?
<clever> o1lo01ol1o: and your sure you have the latest version deployed?
<clever> o1lo01ol1o: nix-env --set or -i?
<clever> o1lo01ol1o: have you rebuild since allowing 443?
<clever> o1lo01ol1o: what is the full message from the logs?
<clever> o1lo01ol1o: the firewall, networking.firewall.allowedTCPPorts i think its spelled
<clever> notgne2: yep
<clever> notgne2: your only option is to put the entire /boot on a non-nvme disk
<clever> notgne2: grub relies on the efi firmware to provide nvme drivers
<clever> CMCDragonkai: depends on the performance you need (re-import is more expensive) and if you want any other config/overlays to also stick
<clever> then just re-import the same dir, with new args
<clever> > import pkgs.path { overlays = []; }
<clever> CMCDragonkai: you can turn a pkgs tree back into a path
<clever> > pkgs.path
<clever> oh, another trick
<clever> which makes it behave a lot more like the overlays= arg to nixpkgs
<clever> CMCDragonkai: and it will chain .extend for you
<clever> CMCDragonkai: you can give foldl' a list of overlays
<clever> CMCDragonkai: there, like that
<clever> > (builtins.foldl' (state: overlay: state.extend overlay) pkgs [ (super: self: { a=1; }) (super: self: { b=2; }) ]).b
<clever> > (builtins.foldl' (state: overlay: state.extend overlay) pkgs [ (super: self: { a=1; }) (super: self: { b=2; }) ]).a
<clever> > builtins.foldl' (state: overlay: state.extend overlay) pkgs [ (super: self: { a=1; }) (super: self: { b=2; }) ]
<clever> ah
<clever> arg0 is a func, arg1 is initial state, arg2 is a list, looks fine so far...
<clever> > builtins.foldl' (overlay: state: state.extend overlay) pkgs [ (super: self: { a=1; }) (super: self: { b=2; }) ]
<clever> and thats where fold comes in
<clever> nix is immutable, so `pkgs.extend foo` wont modify `pkgs`, it will return a new version of pkgs
<clever> (pkgs.extend overlay1).extend overlay2
<clever> you have to run .extend on the result of the previous .extend
<clever> if you want to apply 2 overlays, you need to chain things, or use a fold function
<clever> yep
<clever> > (pkgs.extend (super: self: { hello = 42; })).hello
<clever> CMCDragonkai: .extend
<clever> ah, that must be something else
<clever> monokrome: the new editor may have broken everything, it definitely broke android until i updated

2019-12-09

<clever> ...... ow
<clever> jared-w: hydra.nixos.org has a much bigger DB
<clever> jared-w: half of that is just crap IO thruput on my hardware
<clever> keithy[m]: multi-boot-helper is basically the same as kexec, but it relies on grub to load things, rather then kexec
<clever> keithy[m]: https://hydra.angeldsis.com/project/nixos-configs this project in my hydra, is configured to build all of my nixos configs, against both unstable and stable
<clever> keithy[m]: i would use hydra to automate that testing
<clever> keithy[m]: and with rollbacks, you can undo any upgrade (though autoUpgrade will keep going fowards, undoing a rollback)
<clever> keithy[m]: you wont really notice the problems if your not activating the config
<clever> and i believe it has an option to set the interval
<clever> autoUpgrade is already a systemd timer
<clever> kvda: thats how all derivations work
<clever> kvda: pkgs.hello is a variable that has the path of the hello package
<clever> but if the users dont exist, things will fail
<clever> its fairly simple to generate .service files
<clever> drakonis: i have found ways to reuse systemd.services outside of nixos
<clever> i think it was the unpack channels drv, got turned into rust
<clever> so you have a fully opensource and nix managed os, that can run some darwin binaries
<clever> another thing ive been interested in, is building the xnu kernel, and a very basic xnu userland os, using nix
<clever> and all of the closed-source ELF files
<clever> :D
<clever> fZNxeka75: every time you make any changes to configuration.nix, it will create a new entry in grub, so you can go backwards to any previous state
<clever> selfsymmetric-mu: ive mostly seen peti pushing the generated files, not sure how automated he has it
<clever> fZNxeka75: the hash at the start makes it faster to tab complete
<clever> fZNxeka75: the point of the hash being at the start, is that there is only going to be one path starting with 94n64, but there is going to be 20 paths starting with glibc-2.19
<clever> selfsymmetric-mu: run hackage2nix to update the entire haskellPackages at once
<clever> fZNxeka75: 95% of those contents are symlinks to /nix/store that get updated on every boot (or rebuild switch)
<clever> fZNxeka75: if /etc is missing, nixos will recreate all of the contents on bootup, based on the configured settings
<clever> yep
<clever> kenshinCH: what does `which --all nvim` report?
<clever> lovesegfault: which file did you find it in?
<clever> > lib.flag
<clever> lovesegfault: is there a `flag =` in the same file?
<clever> some may want aarch32 || aarch64
<clever> rather then printing the drv itself
<clever> i think the problem is that `nix eval` on a drv, will eval every attr of the drv
<clever> ah
<clever> infinisil: nix-instantiate --strict
<clever> lordcirth_: --arg config '{}' to exclude it
<clever> lordcirth_: config.nix
<clever> lordcirth_: x86_64-linux
<clever> pikajude_: substituteAll and its related things
<clever> aanderse: that tells nixos to update the /boot files
<clever> aanderse: NIXOS_INSTALL_BOOTLOADER=1
<clever> aanderse: correct, you have to run `switch-to-configuration boot`, possibly with the magic env var set...
<clever> aanderse: thats also where kexec can come in handy
<clever> aanderse: then you can just wipe the whole /boot, all files and dirs
<clever> aanderse: has nixos already booted once?
<clever> aanderse: dont have the same issues as needing /bin to shutdown
<clever> aanderse: it would be simpler to just nuke /boot before you nixos-install
<clever> yorick: and the c2.large.arm has been available since the very start of me monitoring capacity, it must have happened between trying to test it, and setting up monitoring
<clever> in 5 regions
<clever> yorick: i see signs that c2.large.arm is now available
<clever> angerman: though, i also have stuff graphing the packet.net capacity, and it seems to be available now
<clever> also, last time i tried to get aarch64 from packet, they where out of capacity
<clever> angerman: i believe the aarch64 community box is in packet.net
<clever> lovesegfault: and its 4am, was just on my way to bed
<clever> lovesegfault: only aarch64 i currently have access to is an rpi3 and the https://github.com/nix-community/aarch64-build-box
<clever> lovesegfault: hence, why i always recomend wrapProgram
<clever> lovesegfault: so, every time you try to login, it fails, and drops you back to the login screen
<clever> lovesegfault: worse still, if you nix-env -iA any qt package, then later nixos-rebuild --upgrade, and your using KDE, the ENTIRE BLOODY KDE will break upon login
<clever> lovesegfault: propagated-user-env-packages will then put one of those into ~/.nix-profile, breaking whichever package didnt get what it wanted
<clever> lovesegfault: if you install wpa_gui, and wireshark, from different nixpkgs revs, they request conflicting versions of QT
<clever> lovesegfault: for example, https://github.com/NixOS/nixpkgs/issues/30775
<clever> angerman: yeah
<clever> lovesegfault: it also silently collides, and causes all kinds of conflicts (exactly what nix is supposed to prevent)
<clever> lovesegfault: but that will instantly fail when you do nix-build && ./result/bin/foo, and it hasnt been installed by nix-env
<clever> lovesegfault: there is also propagatedUserEnvPkgs (or is it propagatedUserEnvPackages), which will force nix-env to install other things along side your thing
<clever> angerman: this will rename $p (lets call it foo), to .foo-wrapped, then generate a bash script called foo, which prefixes PATH, then runs .foo-wrapped
<clever> angerman: ../nixpkgs/pkgs/development/compilers/opa/default.nix: wrapProgram $p --prefix PATH ":" "${codeGeneratorPaths}" ;
<clever> lovesegfault: it will then look for a $x/nix-support/propagaed-something file, and if present, it will behave as-if the paths within it where already in $buildInputs, and repeat the above
<clever> lovesegfault: it will then add -I$x/include to the cflags, -L$x/lib to the LDFLAGS
<clever> lovesegfault: when the stdenv is starting up, it will loop over every path in $buildInputs, sort of like: for x in $buildInputs; do
<clever> angerman: i would just use wrapProgram to prefix PATH
<clever> so things can leak out into runtime, if you choose to
<clever> angerman: but in some cases (python), it will be used to populate PYTHONPATH (at build time), and then that PYTHONPATH value may get baked into scripts
<clever> angerman: propagatedBuildInputs is only at build time, as far as the stdenv is concerned
<clever> CMCDragonkai: if that happens to be a regular string, then it will wind up impurely pointing to something nix wasnt managing, like /srv/!
<clever> CMCDragonkai: the setup-etc.pl script, expects "${source}" to mutate into a /nix/store path, and will just blindly symlink /etc/ssh/ssh_host_rsa_key to "${source}"
<clever> CMCDragonkai: i think you can do "ssh/ssh_host_rsa_key" = { mode = "0600"; source = "/srv/something"; };
<clever> CMCDragonkai: one min
<clever> CMCDragonkai: another option is to modify the netboot stuff, so it has a persistent local partition mounted to /, for state
<clever> CMCDragonkai: none as far as i know
<clever> keithy[m]: thats why i was skipping nix's copy, but that relies on you having write to /nix
<clever> keithy[m]: you need to install kexec using the host package manager
<clever> CMCDragonkai: that will generate some static ssh host keys
<clever> CMCDragonkai: you can use environment.etc to supply static files, but they will be world-readable in /nix/store
<clever> CMCDragonkai: youll need to make a variant of it, that does something different
<clever> CMCDragonkai: it mounts a tmpfs to /
<clever> CMCDragonkai: the netboot image doesnt let /etc persist
<clever> CMCDragonkai: just let /etc/ persist?
<clever> which is why i said to just read the kexec script, and run the host kexec with the same args
<clever> keithy[m]: you have to run kexec as real root
<clever> keithy[m]: it was -I nixos-config=./configuration.nix
<clever> keithy[m]: what command did you run to get that error?
<clever> keithy[m]: oh, what command did you run, to get that error?
<clever> keithy[m]: should work...
<clever> keithy[m]: `echo $NIX_PATH` ?
<clever> add that to the args
<clever> keithy[m]: -I nixpkgs=channel:nixos-unstable
<clever> and then you can select nixos from the grub menu, and skip kexec
<clever> keithy[m]: then you just copy the kernel/initrd into /boot, and paste grub-fragment.cfg somewhere inside your grub.cfg
<clever> keithy[m]: if you nix-build that, it will generate 3 files, nixos-kernel, nixos-initrd and grub-fragment.cfg
<clever> keithy[m]: something else that may help, and skip the entire kexec layer, is https://github.com/cleverca22/nixos-configs/blob/master/multi-boot-helper.nix
<clever> then the result symlink points directly to the shell script, rather then a tar containing the shell script
<clever> if you already have nix on the machine, you can replace `-A config.system.build.kexec_tarball` with `-A config.system.build.kexec_script`
<clever> keithy[m]: delete lines 20-29, and replace the final.gz on line 31 with ${image}/initrd, and then it will use less disk space
<clever> keithy[m]: you can skip the decompress and re-compress step
<clever> keithy[m]: if its in the configuration.nix you made the tar from, then it will be baked into the initrd and just work
<clever> keithy[m]: thats purely to add /ssh_pubkey to it
<clever> keithy[m]: most of the initrd uncompressing and re-compressing can be skipped
<clever> youll need to read the unpacked one, fix all of the paths, and use the kexec binary the host provides
<clever> keithy[m]: it wont be able to find any dynamic libraries
<clever> keithy[m]: nope, all of the compiled binaries also have /nix/store baked into them
<clever> its a little more manual, but should still be possible
<clever> keithy[m]: you can unpack the tar to elsewhere, read the bash script, and then use the kexec tool already installed into the host
<clever> keithy[m]: probably the man pages
<clever> keithy[m]: it has a total of 592 files
<clever> keithy[m]: everything else you already had in nix-env
<clever> ,locate
<clever> likely man_db or mandoc
<clever> ,locate bin/man
<clever> the MANPATH isnt configured properly then
<clever> keithy[m]: those 4 packages contain the bulk of the man pages youll use in c development
<clever> man-pages posix_man_pages stdmanpages glibcInfo
<clever> nix-shell adds it to PATH without installing it
<clever> nix-env adds them to your profile
<clever> correct, nix-build just builds things
<clever> keithy[m]: ls -l result
<clever> id say thats a bug
<clever> nix-build -p shouldnt even try to build it
<clever> keithy[m]: then nix-build '<nixpkgs>' -A git
<clever> keithy[m]: thats invalid, you want `nix-shell -p git`
<clever> keithy[m]: what command did you run?
<clever> i could rename the files some, others have had the same issue
<clever> keithy[m]: just clone that repo, cd into kexec, add your ssh pubkey to the existing configuration.nix, and run the commands you see in `session.md`
<clever> that 1st configuration.nix, is the config for the kexec system
<clever> keithy[m]: you must use the configuration.nix in the directory session.md is in
<clever> so after you kexec, you can treat it like a normal livecd boot
<clever> the kexec gives you full nixos, with real root and nixos-generate-config in $PATH
<clever> keithy[m]: nixos-generate-config will create one for you
<clever> simpson: yeah, that kind of thing needs rips