<clever>
gchristensen: thats why i passed -host grahamc.com
<clever>
LnL: do both of your machines have v6 support?
<clever>
all 4 V4 IP's return github certs and should trigger cert warnings
<clever>
gchristensen: 185.199.108.153 returns a github cert for me
<clever>
let me check each...
<clever>
i see 8 IP's behind that domain
<clever>
gchristensen: what IP do you see behind the domain?
<clever>
gchristensen: This server could not prove that it is grahamc.com; its security certificate is from www.github.com. This may be caused by a misconfiguration or an attacker intercepting your connection.
<clever>
gchristensen: Attackers might be trying to steal your information from grahamc.com (for example, passwords, messages, or credit cards). Learn more
<clever>
adelbertc: thats something else i believe
<clever>
adelbertc: apple doesnt update $HOME when you do that, so it operates on the wrong user
<clever>
adelbertc: and you cant `sudo nix-channel --update` because apple
<clever>
mightybyte: you need a nixbld group, with a number of build users within it
<clever>
mightybyte: last i checked, the linux installer only does single-user installs, which only work as the user that installed it, which cant be root
<clever>
mightybyte: if you lack a nixbld group, then it only works when ran as a non-root user
<clever>
kalbasit: yeah, that looks like its all good now
<clever>
kalbasit: and `cat /root/.nix-channels` ?
<clever>
kalbasit: you forgot to run `nix-channel --update` after adding a channel
<clever>
kalbasit: ls /root/.nix-defexpr/channels/nixos/
<clever>
kalbasit: and as root, what does `nix-channel --list` say?
<clever>
kalbasit: and as root, what does `nix-channel --list` say?
<clever>
kalbasit: what if you instead run `sudo -i` then `nixos-rebuild test`
<clever>
tenten8401: nope
<clever>
and then the default buildPhase will run make with that param for you
<clever>
you could set: makeFlags = [ "CURRYFRONTEND=${curryBase}" ];
<clever>
WilliamHamilton: why do you need that path in the nix shell?
<clever>
WilliamHamilton: thats because its part of $buildInputs
<clever>
WilliamHamilton: your already doing that on lines 52, 56, and 59
<clever>
WilliamHamilton: just put curryBase in buildInputs
<clever>
WilliamHamilton: buildInputs is an array of nix values
<clever>
WilliamHamilton: it doesnt have to be an attribute to use it in buildInputs
<clever>
WilliamHamilton: so its not a bash variable, only a nix value
<clever>
WilliamHamilton: its no longer an attribute on the derivation
<clever>
WilliamHamilton: this is how most things do it
<clever>
postUnpack = "sourceRoot+=/engine-io-wai; echo source root reset to $sourceRoot";
<clever>
yeah
<clever>
WilliamHamilton: because the default sourceRoot is the name of the directory tar -xf made
<clever>
WilliamHamilton: sourceRoot
<clever>
nbathum: user not found? lol
<clever>
zduch4c: did you set isNormalUser = true; when creating the user?
<clever>
WilliamHamilton: in any of the phases/hooks
<clever>
WilliamHamilton: and every attribute on the derivation becomes an env var for that derivation
<clever>
WilliamHamilton: every derivation in nix has a builder and some args, typically the builder is a bash script
<clever>
WilliamHamilton: at the bash level
<clever>
it will search the pkgs attribute set for each of the args
<clever>
WilliamHamilton: it still has to be loaded with callPackage
<clever>
WilliamHamilton: you can put each of those derivations into their own files, and just run nix-build on the parts
<clever>
tester123: nixpkgs.overlays is a nixos option
<clever>
WilliamHamilton: the default unpackPhase will handle directories and .tar.gz files automatically
<clever>
WilliamHamilton: depends on which fetch function was used
<clever>
WilliamHamilton: usually is, but you can also do src = ./.;
<clever>
if those are moved into the let block, the rec can likely be removed
<clever>
yeah
<clever>
he instead refers to them at the nix level, on lines 61, 65, 68, and 109
<clever>
the author of this file sort of messed up, and never actually uses those bash variables
<clever>
and because 26 and 50 are inside the set for line 22, they become env variables inside that derivation, so you can access them at $curryBase and $curryFront
<clever>
50 defines how to build curry front
<clever>
so it must build line 7, before it can start building line 26
<clever>
26 then defines how to build currybase, and it refers to 7 at line 33
<clever>
because 15 is refered to by 12, it will always build 15 before it starts to build 12
<clever>
line 15 creates another derivation to fetch a .tar.gz
<clever>
line 12 creates a modified version of swiProlog
<clever>
WilliamHamilton: line 7 creates a derivation that fetches a .tar.gz
<clever>
WilliamHamilton: there are a total of 5 derivations in that file
<clever>
they should have probably used sourceRoot, not a symlink
<clever>
and then postUnpack will modify the unpacked source
<clever>
the unpackPhase will unpack $src
<clever>
WilliamHamilton: because ${fsrc} is the path to a .tar.gz, not a directory
<clever>
WilliamHamilton: all arguments passed to mkDerivation become env vars within the derivation, and the stdenv will run a bash script that will process them all
<clever>
WilliamHamilton: postUnpack is called after unpacking the source, within the derivations builder
<clever>
WilliamHamilton: after unpacking the source, it will rename it, then make a symlink
<clever>
WilliamHamilton: ah, lines 42-45
<clever>
WilliamHamilton: does that subdirectory even exist within the tar on line 8?
<clever>
WilliamHamilton: that just sets the src for curry-base to be the result from line 7
<clever>
Taneb: you can easily have a derivation that generates that directory, and then set that as an attribute in the derivation you run nix-shell on
<clever>
Taneb: you could use a shellHook for that
<clever>
Taneb: only nix-build, not nix-shell
<clever>
Taneb: every nix build happens in a directory under /tmp/ that is auto-created, and deleted when the build finishes
<clever>
Taneb: nix-build always does that
<clever>
gchristensen: that is strange
<clever>
and you reinstall daily to change
<clever>
not what you happened to install last
<clever>
nix-shell always provides the one that shell.nix asks for
<clever>
it also entirely avoids the problem of different projects needing different versions of ruby
<clever>
kalbasit: thats what nix requires, for developing with any language
<clever>
kalbasit: make a shell.nix that has ruby in the buildInputs, and run nix-shell to get access to ruby
<clever>
when using nix
<clever>
kalbasit: things like ruby usually arent supposed to be installed
<clever>
yeah, that would also work out well
<clever>
kalbasit: you could make an override that joins the 2 packages using buildEnv, and set ignore collisions to true, then install that override instead
<clever>
just note that the symlinks will be resolved, so you need to read the links in /run/opengl-driver and confirm its loading the right one, one not from -qR
<clever>
acowley: you can check /proc/<PID>/maps to see what libraries it has loaded while running
<clever>
acowley: and check with nix-store -qR to see if libGL is somehow winding up as a runtime dep anyways
<clever>
acowley: you could try to diff the good and bad derivation, both with `diff -u -r` on the results, and nix-diff on the .drv's
<clever>
but thats all at build time
<clever>
setup hooks within libGL still run, and can mutate the stdenv of whatever was depending on SDL2
<clever>
acowley: all that does, is automatically add libGL to the buildInputs of anything that has SDL2 in the buildInputs
<clever>
acowley: note that propagatedBuildInput's are not available at runtime
<clever>
countoren: pkgs.vim_configurable.customize can still build on darwin
<clever>
countoren: you would need to look into how nixpkgs generates it
<clever>
countoren: so its not really possible to access the config derivation in an automated manner
<clever>
countoren: the derivation returned by `pkgs.vim_configurable.customize { ..}` is just a pkgs.writeTextFile call, to generate a $out/bin/vim with contents like "#!/bin/sh\nexec /nix/store/9p4kzfi2kg5hfhh1j3dbjz96arpcd4b3-vim_configurable-8.0.1451/bin/vim -u /nix/store/39wqqljfmvhv2v59k59jkn80pa4n02k9-vimrc \"$@\"\n"
<clever>
countoren: i dont see any easy way to do it from the nix side, what do you want to do with it?
<clever>
vajralambda: if you want to edit things, you need to clone nixpkgs from github
<clever>
vajralambda: you cant edit either one, the entire /nix/store is read-only
<clever>
Edes: yeah, mount the existing efi partition to /mnt/boot after mounting your rootfs to /mnt/
<clever>
Edes: i think you can share the efi partition between both systems
<clever>
srk: lets take this to #nixos-aarch64
<clever>
srk: i put the rpi ontop of the desk fan, since its overheating before it even gets to start.elf
<clever>
that will show the logs from the previous bootup
<clever>
ambro718: after it fails to boot, connect a monitor and reboot, then run `journalctl -b -1`
<clever>
srk: its overheating to the point of malfunctioning, lol
<clever>
srk: got distracted, then i found the pi sitting at kgdb (kernel debugger), with a thermometer in the corner
<clever>
bpye: not currently
<clever>
srk: changing absolutely nothing on the netboot server, replugging the the rpi, and watching tftp, results in it loading the 1st file pattern again
<clever>
bpye: i lookup the rev of a channel i want to use, and then run this with the rev
<clever>
srk: there is something else, let me find it
<clever>
srk: i have considered abusing the LCD and camera connectors as high-bandwidth
<clever>
srk: the connector on the compute modules gives you access to hdmi, gpio, the camera and lcd connectors, a single usb port, jtag and composite video
<clever>
srk: the compute module saves you from having to deal with the fine pin-pitch and picky signal routing of ram lines, so you can just work with "low-bandwidth" usb and hdmi
<clever>
srk: the compute module is more for when you want to make a custom device, and dont need half the junk on an rpi
<clever>
srk: oh, and for the model A's and compute module, you can boot over USB, with the rpi rom acting as a usb slave
<clever>
srk: it does support booting from a serial flash chip
<clever>
if you have an sd card with ONLY bootcode.bin (it must not have ANY other file), then it will act like it has no card at all, and try other enabled modes
<clever>
the docs claim that is possible, but a bug in the boot rom stops it from working on mine
<clever>
bootcode.bin starts the dram controller, and then requests start.elf over tftp
<clever>
thats the rpi3 firmware
<clever>
srk: so every pi can have its own image
<clever>
srk: in my setup, the rpi firmware uses its serial# to uniquely address a tftp directory
<clever>
Jul 10 20:00:29 router tftpd[17554]: tftpd: trying to get file: 9080d9b6/root.squashfs
<clever>
Jul 10 20:00:06 router tftpd[17500]: tftpd: trying to get file: 9080d9b6/kernel7.img
<clever>
Jul 10 20:00:01 router tftpd[17438]: tftpd: trying to get file: 9080d9b6/start.elf
<clever>
srk: in my case, it saves every build in a nix profile, so i have rollback support
<clever>
srk: the above command will build the rpi_image derivation of release.nix, then create a new generation of the rpi3-netboot profile, pointing to the result
<clever>
srk: and here is the incantation i used for the not-os image: [root@router:/tftproot/try2]# nix-env -p /nix/var/nix/profiles/per-user/root/rpi3-netboot -f not-os/release.nix -A rpi_image -I nixpkgs=./nixpkgs/ --set
<clever>
pip3000: and in addition to that, i also have zfs snapshots enabled, so i can diff any file on the entire machine, over almost any time-period
<clever>
pip3000: so after a rollback, i can look in there to see what the old config was
<clever>
pip3000: that saves a complete copy of the directory containing core.nix at /run/current-system/nixcfg
<clever>
for xfs, it happens with any volume over 2tb in size
<clever>
it only happens when a 64bit capable FS is shared to a 32bit client over NFS
<clever>
srk: so all of your builds claim file not found, when the file clearly exists
<clever>
srk: the inode numbers dont fit into a 32bit field, and half the packages on nixos tread EOVERFLOW as an empty directory
<clever>
srk: zfs/xfs totally break 32bit nixos over nfs
<clever>
srk: i ran tgtd on gentoo, i tried to do some fancy things with the tgtd nixos module but it never worked 100% right
<clever>
pip3000: i keep a git repo at /etc/nixos/nixcfg/ with 1 file for each host, and then configuration.nix is just the bare-minimum required to boot, and imports = [ ./nixcfg/hostname.nix ];
<clever>
srk: it pre-dates the network support in the initrd, so it may need updating