2020-12-16

<clever> energizer: i think you could just `cd /mnt` and then `/kexec_nixos`, since it just drops the temp files in the current dir
<clever> energizer: you could also just format and mount the target disk
<clever> energizer: `df -h` ?
<clever> KarlJoad: but pkgs.fetchurl and pkgs.fetchzip are derivations, it just describes how to fetch something later, once the eval is done, nix can do all of the fetching in parallel
<clever> KarlJoad: builtins.fetchurl and builtins.fetchTarball are both eval time fetches, so that forces it to download things in series, and to stop evaling while it waits on network
<clever> when it winds up causing a build at eval time
<clever> ,ifd
<clever> builtins.fetchTarball isnt allowed in nixpkgs itself, since its IFD
<clever> KarlJoad: pkgs.fetchurl keeps the disk usage down more
<clever> energizer: mkdir /nix ; mount -t tmpfs none /nix
<clever> energizer: to simplify the build, it assumes the binaries will still be in /nix/store on the target
<clever> colemickens: i dont know why, but they are missing when using remote build machines, but present when building locally
<clever> energizer: the tarball must be unpacked to / so that the files are in /nix/store/hash-foo like normal
<clever> energizer: the configuration.nix your first building, is for the ramdisk, not the target install
<clever> energizer: you need to use the configuration.nix in that directory
<clever> you can then run `justdoit` to install, or follow the normal fdisk+mkfs+mount+nixos-install directions
<clever> energizer: the steps in this example get you nixos running from ram
<clever> theres also kexec and justdoit
<clever> energizer: cat will just paste the 2 files together, and feed it to a /bin/sh on the remote box, which runs each line
<clever> energizer: i think thats just your own shell code, that gets ran before nixos-infect

2020-12-15

<clever> terlar: ah, not sure then
<clever> terlar: why are you running cleanSource on a derivation? why not just not include the files in $out ?
<clever> terlar: why do you need unsafeDiscardStringContext?
<clever> terlar: and readDir forces it to build it much earlier, at eval time, which can harm performance
<clever> terlar: unsafeDiscardStringContext gets rid of the data needed to let nix know it wants to build it
<clever> kdb, lightdm, those feel like things that cant reload at runtime, so you could just pass it on the cli args, if the app allows it
<clever> but they have no other way of knowing WHERE the new config is
<clever> pulse, same reason, the config can change when you rebuild, and all apps should respect the new config
<clever> so you need a symlink at some predictable location, which you can swap out later on
<clever> and an env var wouldnt take effect until you restart nearly everything
<clever> energizer: but the path to /etc/nsswitch.conf cant be in an env var or wrapper, because it should use the new config after you rebuild-switch
<clever> energizer: yeah
<clever> but with vim, my config is baked right into a shell script that claims to be vim
<clever> energizer: for that, i would say its so `nix-env -iA nixos.nano` will respect configuration.nix, without having to know its path
<clever> and syslog then forwarded the logs to the right box, lol
<clever> the router forwarded 22 to the wrong box
<clever> then i realized, the hostname in the log msg, syslog was merging both systems into one file
<clever> the logs turned up in /var/log/ssh, yet the error says the acct doesnt exist, and it does
<clever> and then i spent 2 hours trying to figure out why somebody cant ssh into my machine
<clever> i rigged syslog up to do that on some of my pre-nixos machines ages ago
<clever> that reminds me
<clever> bqv: run `nix-store -r` on the path
<clever> world-readable on my end
<clever> -r--r--r-- 1 root root 33 Oct 11 2015 /etc/machine-id
<clever> ronthecookie: i had the same basic problem in iptables, because i wanted to append things to a non-standard chain, but nixos was creating it later
<clever> yeah, lol
<clever> theres also #nixos-on-your-router
<clever> ronthecookie: its basically just a random server board that has 2 gigabit ports on the mobo
<clever> ronthecookie: mkOrder and mkAfter
<clever> pinpox: yep
<clever> pinpox: the `--upgrade` just runs `nix-channel --update` for you, which puts you on the latest release of the current channel
<clever> pinpox: "error: unrecognised flag '--experimental-features'" means the nix is too old to understand that config option
<clever> pinpox: depends on how your setting the nixpkgs for each macine, i dont know how krops works
<clever> fgaz: ah, maybe the link i gave to thibm was for your issue
<clever> pinpox: yeah, one of them is older by ~1000 commits
<clever> pinpox: nix eval -f '<nixpkgs>' lib.version ?
<clever> pinpox: which channel and nixpkgs rev are they on?
<clever> pinpox: and `nix --version` ?
<clever> pinpox: either should work, what does `which nix` say?
<clever> pinpox: i recently had that, it was solved with `nix.package = pkgs.nixUnstable;` in configuration.nix
<clever> pinpox: i'm guessing only krops has to support flakes then, and the remote machine wouldnt need to
<clever> pinpox: if you build it on one machine (with flake support), then you can nix-copy-closure it to the other machine, and it wont care how you built it
<clever> and a sha256 capable git can re-hash it with sha256, and validate that signature too
<clever> a sha1 only git will only see/care-about the old sha1 signature
<clever> and shove both signatures into the final commit object
<clever> henri: aha, they just sign it twice now, over both the sha1 and sha256 encodings
<clever> > It is similar to the existing "gpgsig" field. Its signed payload is the sha256-content of the commit object with any "gpgsig" and "gpgsig-sha256" fields removed.
<clever> the tree and parent will differ, both because your changing the hash algo used to name them, and because the contents your hashing differs
<clever> i believe the signature covers the tree, parent, author/commiter(with timestamps) and the commit msg
<clever> the signature is over the serialized form of that
<clever> henri: `git cat-file commit HEAD` will pretty-print the latest commit
<clever> so a commit has 2 radically different contents, depending on how you hashed it
<clever> and that tree object has the sha256 hashes of further trees and objects
<clever> and the commit content has the sha256 of a tree object
<clever> henri: but the new commit hash is a sha256 over the commit content
<clever> henri: but i dont see how commit signatures will work, because that mutates the commit contents
<clever> henri: so it can turn your history back into a sha1 format for pushing to older servers
<clever> henri: looks like it will seamlessly translate all objects (recursively) between sha1 ans sh256 formats
<clever> nf: nixos is the last commit of release to pass a set of tests

2020-12-14

<clever> KarlJoad: if you use a sourceRoot of ${src}/src, then the source is now readonly
<clever> KarlJoad: the unpackPhase will copy $src to . then set sourceRoot to be the name of whatever dir appeared

2020-12-12

<clever> with things like the cut command
<clever> you can just strip it out then
<clever> when a derivation has multiple outputs
<clever> jneto: that your refering to the output named bin

2020-12-08

<clever> alienpirate5: `file ~/.local/share/Steam/steamapps/common/Cities_Skylines/Cities.x64` ?

2020-12-05

<clever> and you can create .o files from c++ or haskell too
<clever> yeah
<clever> but once its in a .drv, you cant do overrides or overlays
<clever> fuzzypixelz: and .overrideAttrs lets you mutate things before the list has been turned into a flat string
<clever> fuzzypixelz: the stdenv will conditionally switch between host and target based on other things
<clever> fuzzypixelz: the drv file is the result of running the exprs, after everything gets shuffled around
<clever> fuzzypixelz: the seperation lets you do things like guix, use a completely different expression language to create .drv files, which nix-daemon can still build without changes
<clever> ishan: libudev
<clever> ,locate libudev.h

2020-12-03

<clever> mtr: this code is able to build for both linux and windows, entirely within a pure nix sandbox

2020-12-02

<clever> o1lo01ol1o: you can use runCommand to mutate the src, and then provide that mutated src to callCabal2nix
<clever> hpfr: cant remember

2020-12-01

<clever> Filesystem Size Used Avail Use% Mounted on
<clever> nas:/nas 6.6T 6.6T 31G 100% /nas
<clever> and similar
<clever> hyper_ch: "Persistent L2ARC" ooo, that could help with boot times
<clever> nope
<clever> Henson: then the service is being installed, and you just need to `systemctl start sshd` or mkForce wantedBy
<clever> Henson: check `ls /etc/systemd/system | grep ssh` ?
<clever> Henson: how did you check for it?
<clever> Henson: prior to this change, sshd was installed but not setup to run on bootup
<clever> Henson: on wantedBy, getting an example...
<clever> Henson: you need to use mkForce, one sec

2020-11-29

<clever> Reventlov: put them in roots ~/.ssh/config

2020-11-27

<clever> ive done the same thing, back before i was committed to nixos
<clever> vvvvv84: you can then use the include statement in another grub.conf file, to import the nixos grub.conf
<clever> vvvvv84: but it will still update the config in /boot, so give nixos its own /boot (which could be in the / partition)
<clever> vvvvv84: if you use grub, and set boot.loader.grub.device = "nodev";, then it wont install into the MBR
<clever> tomturbo: { pkg = buildEnv ...; inherit mycacert; }
<clever> tomturbo: only way to access that, is to have the file return a set rather then a package
<clever> no need for a bind mount
<clever> adisbladis: in the nix-msd example i linked above, i just symlink /bin to ${foo}/bin
<clever> the buildCommand will just eval it after the perl script ran things
<clever> 78 ${buildPackages.perl}/bin/perl -w ${builder}
<clever> 79 eval "$postBuild"
<clever> postBuild
<clever> adisbladis: buildEnv has a hook for that
<clever> but that attr only exists if you get cmake from callPackage
<clever> > cmake.__spliced
<clever> simonpe^^: behind the scenes, nativeBuildInputs is using __spliced to extract the native version of cmake from the set, when "${cmake}" is target
<clever> { buildBuild = «derivation /nix/store/5p4lh26b6f5wm92v4gpsblfy682z8qw9-cmake-3.18.2.drv»; buildTarget = «derivation /nix/store/3hfna44b732w9n31hl6dl24xr0g6imv5
<clever> nix-repl> x.__spliced
<clever> nix-repl> x = pkgsCross.armv7l-hf-multiplatform.callPackage ({cmake}: cmake) {}
<clever> [nix-shell:~/apps/rpi/lk]$ nix repl '<nixpkgs>'
<clever> simonpe^^: but if your not using callPackage, that magic breaks
<clever> simonpe^^: callPackage does some magic, so nativeBuildInputs can find the right cmake
<clever> but only if you rewrite everything
<clever> simonpe^^: the initrd is 2mb in size, so it would fit your needs, lol
<clever> (assuming the other programs are also haskell)
<clever> and being static, it relies on nothing
<clever> simonpe^^: and being haskell, you can cheaply embed other programs into the same binary
<clever> simonpe^^: this generates a single haskell binary at /init, and ZERO other files
<clever> simonpe^^: i also have another more extreme option...
<clever> it needs to be extracted out and made generic, so others can then easily recycle it
<clever> but that code is geared towards running the nixos stage-1-init.sh, script
<clever> this is how nixos does it, to make the initrd smaller
<clever> and discard all the unwanted files
<clever> simonpe^^: you can move all of the binaries and libs into a single $out, and then re-patchelf them to look in the new dir
<clever> simonpe^^: the other option is patchelf
<clever> yeah
<clever> simonpe^^: that would leave you free to move the binaries around without things breaking, but it may wind up larger, because your not sharing libc between each binary
<clever> simonpe^^: ah, thats a bit more complex, i tend to just do everything the nix way
<clever> simonpe^^: lines 117-135 says to create symlinks at /init, /lib/modules, /bin, and /etc, so i dont have to force modprobe too heavily, and the $PATH is simpler
<clever> simonpe^^: but the nix binary itself is absent
<clever> simonpe^^: nope, it has a full /nix/store within the initrd, and a /init symlink at the root so the kernel is happy
<clever> simonpe^^: this will cross-compile a bunch of things to armv7l, and package them all up into an initrd
<clever> simonpe^^: one minute
<clever> tomturbo: you would want to wrap 30-60 in ( and ) i think
<clever> tomturbo: line 30 is to blame, the let block is only in scope during 30 i think
<clever> mounty: nix-locate and nix-index
<clever> tomturbo: can you pastebin the whole expr?
<clever> could just be an old version, `sudo nix-channel --update` may fix it, but will also update the versions of some things
<clever> mounty: `sudo nix-channel --list`
<clever> mounty: it relies on having a channel called nixos on root, are you using channels or flakes?
<clever> mounty: qt5.qttools
<clever> ,locate
<clever> dang, he ran off!
<clever> zakame: <nixpkgs/pkgs/development/compilers/dmd/binary.nix>
<clever> ah, not sure then
<clever> colemickens: run `nix show-derivation` on the .drv file that failed, what URL is it loading?
<clever> "lib.or" and "or" are also different
<clever> "or" and "||" are different operators
<clever> typetetris: like that?
<clever> > let set = { a=42; }; in set.a or "fallback"
<clever> > let set = { a=42; }; in set.b or "fallback"

2020-11-26

<clever> bqv: is /etc/resolv.conf setup right? can you ping 8.8.8.8?

2020-11-25

<clever> cole-h: my irc client cant render emoji
<clever> gchristensen: it might be specific to switch-to-configuration boot
<clever> cole-h: but grub's boot code, can boot things that are not generations
<clever> cole-h: for extra complication, boot doesnt really work on systemd-boot, since that can only boot what is a valid generation
<clever> sss2: though i'm not sure on the other part of the error
<clever> sss2: you want --argstr system i686-linux

2020-11-24

<clever> dstzd: pretty sure that recurseIntoAttrs is only ever to make nix-env play nicely, and can usually be ignored
<clever> yeah, nixos only needs a channel named nixos
<clever> there is also a `nix-channel --rollback`, but its a bit fuzzy on how many times you have to rollback, because you made so many changes
<clever> which tells it to fetch the latest version of all channels
<clever> you ran `sudo nix-channel --update`
<clever> daf58: a list of every change in 20.09
<clever> 14 hours ago, it got a change
<clever> but 20.09 changed slightly
<clever> and it updated software
<clever> thats because your --update changed you to the latest nixos-20.09
<clever> you dont need the nixpkgs entry, only nixos
<clever> what is the latest output from `sudo nix-channel --list` and does switch now work?
<clever> did you --update as root? and --list as well
<clever> and then it should just work
<clever> but the url can be diff
<clever> the channel must have a name of nixos
<clever> daf58: youll need to re-add it, as root
<clever> daf58: it looks like you removed the main nixos channel entirely
<clever> ,unstable daf66
<clever> that can return a nixpkgs rev, if your on a channel
<clever> > lib.version
<clever> yep
<clever> ive not done much with node2nix and have never heard of nexe, so fixing it further would take some investment of time
<clever> daf66: and now you can either use those nix files as-is, or start to modify them to use niv to fetch nexe
<clever> i think
<clever> ah, then just nix-build -A buildNodePackage
<clever> let sources = import ./nix/sources.nix; pkgs = import sources.nixpkgs {}; { foo = (pkgs.callPackage ./node-env.nix {}).buildNodePackage; }
<clever> daf66: youll want a default.nix that does something like this:
<clever> daf66: what are the contents of node-env.nix?
<clever> it may be possible to use IFD with node2nix and niv, but when starting out, its simpler to work from a git clone
<clever> thats how node stuff is handled
<clever> yeah
<clever> and it should then create a nix file for you
<clever> daf66: you must run node2nix outside of nix
<clever> it will auto-generate a yarn.nix that can do network operations, based on a yarn.lock input
<clever> daf66: you want to use something like yarn2nix
<clever> daf66: add `export HOME=$NIX_BUILD_TOP` to the buildPhase
<clever> daf66: try using buildPhase = ''shell code''; instead
<clever> daf66: but you replaced the builder, and none of that is helping anymore
<clever> daf66: because the default builder puts buildInputs into PATH for you
<clever> usually, its a sign that your using nix wrong
<clever> also, you almost never want to set builder
<clever> siraben: they look pretty much identical, what about file on the ld-linux-armhf?
<clever> siraben: run the file command on a binary that works, and a binary that doesnt work, how do they differ?

2020-11-23

<clever> and further down, i rig up the nat and dhcp
<clever> mkaito: this will create 2 custom interfaces, named wan and iptv, which are using the given vlan id's off of enp4s2f0
<clever> yeah
<clever> so it acts as an overview of which files are involved in cross-compile setup
<clever> ali1234: that is a PR where i added a new gcc, to support cross-compiling to vc4/vc6
<clever> ali1234: depends on if you want to change overall gcc flags, or just the stuff for one package
<clever> ali1234: its a functional programming language
<clever> ali1234: its an attribute set containing every possible cross-compile target, and each one will build all of nixpkgs for a given target
<clever> `nix repl` lets you explore any given nix expression, and try out new ones
<clever> ali1234: run `nix repl '<nixpkgs>'` and then tab-complete with `pkgsCross.`
<clever> *waves*

2020-11-22

<clever> 2020-11-22 00:14:53 < clever> bqv: try just fetchurl then, and add lzip to nativeBuildInputs
<clever> 2020-11-22 00:14:48 -!- bqv [~bqv@2a02:8010:674f:0:d65d:64ff:fe52:5efe] has quit [Quit: WeeChat 2.9]
<clever> but there is a nixops deployment under deployments
<clever> no flakes in there yet
<clever> yeah
<clever> bqv: try just fetchurl then, and add lzip to nativeBuildInputs
<clever> bqv: fetchzip will unpack for you, fetchurl never unpacks
<clever> bqv: you may need to fix the build of nix then
<clever> bqv: that one
<clever> > "${nix.out}/share/nix/corepkgs/"
<clever> bqv: you can use -I nix=... to remap that to the right dir

2020-11-20

<clever> ,escape ${foo}
<clever> jackdk: there can also be multiple .narinfo files that depend on a single .nar.xz
<clever> jackdk: a given path must have its entire closure on the bucket, or its invalid
<clever> comment added
<clever> gchristensen: the if statements get hairy when trying to do X if Y or Z, id want a proper editor with some syntax highlighting
<clever> which also means any nixpkgs between the break and fix, will remain broken
<clever> gchristensen: i think you would need to keep the old logic as a fallback
<clever> even if the user needs one
<clever> gchristensen: what happens if i use your new nixos-install, on an old nixpkgs?
<clever> because uid-map is corrupt, and that is state which must persist
<clever> it continues to happen, even if you undo the changes in configuration.nix
<clever> yes
<clever> gchristensen: until perl OOM's your machine on boot
<clever> gchristensen: uid-map doubles in size every time you boot
<clever> its horid!
<clever> have you see what happens if you have unicode in your username?
<clever> that also reminds me
<clever> that can also work
<clever> then nixpkgs cant have passwd when we dont want it
<clever> gchristensen: what if we checked that passwd is actually gone like we expected it, and fail out?
<clever> typically used to generate mime-info caches
<clever> gchristensen: a chunk of shellcode that is ran after buildEnv merges everything in systemPackages
<clever> 104 extraSetup = mkOption {
<clever> nixos/modules/config/system-path.nix: system.path = pkgs.buildEnv {
<clever> plan b...
<clever> it requires a copy of configuration.nix to function, which bans certain nixops styles
<clever> that old test wont work when deploying a pre-built nixos
<clever> although....
<clever> gchristensen: git show 806e88c13771e5ec336f3ca14969c5f314482a67
<clever> gchristensen: restore the old test?
<clever> gchristensen: symlink nologin to $out/bin/ ?
<clever> that installers ... uhhh
<clever> lrwxrwxrwx 1 root root 66 Dec 31 1969 /run/current-system/sw/bin/nologin -> /nix/store/kjsk4vpfjhynxn7x0bn8q4z26z0rq9kb-shadow-4.8/bin/nologin
<clever> make a new package, called nologin
<clever> 157 default = pkgs.shadow;
<clever> 158 defaultText = "pkgs.shadow";
<clever> yep
<clever> when shadow got fixed, it started passing that test