<clever>
nixpkgs master is never rebased, would break too much
<clever>
feep: which repo?
<clever>
jophish: i'm thinking, dont change too much at once
<clever>
jophish: or just run `systemctl status > /dev/ttyS0`
<clever>
jophish: next thing 'm thinking of is maybe a systemd timer to do something on /dev/ttyS0 at regular intervals?
<clever>
does anything appear after the last thing in the console? when you left it idling
<clever>
using that, you can read the logs on the SD card
<clever>
jophish: journalctl --root=/path
<clever>
one min
<clever>
jophish: and it likely lacks anything fancy like acpi to signal a clean shutdown?
<clever>
jophish: does it have a usb host interface?
<clever>
jophish: is the tx line wired up right, what happens when you mash enter?
<clever>
jophish: is it hanging, or just not running a serial getty?
<clever>
jophish: nice
<clever>
dont ask me why the dir has to be so complex :P
<clever>
nikivi: its somewhere in /private/var/folders/5l/5s7qw5ld1xxglm0094_hyh_c0000gn/T/
<clever>
nikivi: apple has to be different :P
<clever>
feep: oooo!, that makes a lot more sense!
<clever>
nikivi: and then compare the procs using cpu in `top` or `htop` with the owners of the nix-build-* dirs
<clever>
nikivi: `ls -ltrh /tmp/`, the names of all packages building are in ah you already found that dir
<clever>
roots channels are also the default for other users
<clever>
you removed your own read access
<clever>
feep: you wanted to add the 1000 bit, not make it only 1000
<clever>
feep: ls -lh /nix/var/nix/profiles/per-user/root/channels
<clever>
without the : at the end, oops
<clever>
feep: ls -lh /nix/var/nix/profiles/per-user/root/channels/nixos:
<clever>
feep: what does ls -lh say about that path?
<clever>
thats the channel
<clever>
or wait no
<clever>
feep: your ~/.nix-profile isnt setup right
<clever>
feep: what was the error?
<clever>
with import <nixpkgs> {}; callPackage ./otherfile.nix {}
<clever>
if the file starts with { stdenv }: then it must be loaded with callPackage, from another file
<clever>
then just run nix-build
<clever>
feep: create a file called default.nix, with the following contents: with import <nixpkgs> {}; stdenv.mkDerivation { name = "name"; src = ./.; }
<clever>
steveeJ: enless you flip on the removable flag ing rub
<clever>
steveeJ: efi usually needs special efi vars to boot, and no other machine will know to boot it
<clever>
steveeJ: though you could do both legacy and efi at once
<clever>
steveeJ: and make sure it boots via legacy, not efi
<clever>
steveeJ: just install to that usb device as normal
<clever>
and resolv.conf becomes static as well, so your dns cant be based on dhcp
<clever>
jophish: openssh refuses to use a world-readable private key
<clever>
jophish: i could make /etc/ a static symlink to a storepath, but then its a bit more tricky to build up /etc, and every /etc file is world readable
<clever>
jophish: yeah
<clever>
jophish: for setup-etc.pl and managing /etc/
<clever>
sadly, not-os depends on perl at runtime
<clever>
jophish: that can happen if you hit the max-jobs on nix.conf, or are depending on something another nix cmd was already building
<clever>
i did have my hydra building that on an rpi, but it hasnt been booting reliably lately
<clever>
jophish: i think thats a native arm build, not a cross
<clever>
jophish: yep
<clever>
jophish: console=tty0 is still present, so the true cause isnt visible
<clever>
the tricky part, is getting host deps in the right spots, so you can copy files and assemble the image without an arm device
<clever>
jophish: using a combination of localSystem and something else, you can rig up cross-compiling
<clever>
ekleog: and does nix-channel --list show it as having a channel?
<clever>
i hate those other ones, they make a total mess of your downloads folder
<clever>
jophish: ah yeah, all of the unpack stuff assumes its a tar/zip with a single rootdir
<clever>
jophish: yeah
<clever>
so it instead unpacks, and operates on the hash of the files within
<clever>
the reason it auto-unpacks, is because a lot of libraries for generating a zip include wildly varying timestamps, and then the hash of your zip keeps changing, so nix cant work
<clever>
its a bit poorly named, fetchzip is just a modified form of fetchurl, that has added zip support, and will auto-unpack
<clever>
fetchzip can do that then
<clever>
jophish: does it have to be unpacked in the store, or just at build time?
<clever>
dramforever: ive also memorized how it works, and never knew it was in the docs, lol
2018-10-27
<clever>
thats better then any monitor i have can do!
<clever>
i dont think the above is documented fully, but ive not re-read the docs in a while
<clever>
file:///path/to/dir i believe will generate a pile of .nar.xz and .narinfo, that could then be rsync'd to an http server and act as a binary cache
<clever>
s3://bucket will work for amazon S3 buckets
<clever>
ssh://host and ssh-ng://host will work over ssh to a remote nix
<clever>
local?root=/mnt/ will make it emulate a chroot before working on a localstore (it just prefixes all paths with /mnt/)
<clever>
daemon is for connecting to nix-daemon via /nix/var/nix/daemon-socket/socket
<clever>
local tells it to just open /nix/store/ directly
<clever>
the store-uri for --from and --to supports several schemes
<clever>
not really, but you can `nix copy --help` to get most of the args
<clever>
--no-check-sigs do not require that paths are signed by trusted keys
<clever>
i believe that will just copy everything in /mnt/nix/store to /nix/store/
<clever>
schmittlauch[m]: looks like plasma and some random installer failures
<clever>
andi-: does that test reveal any behaviour differences between user@host and ssh-ng://user@host in the machines file?
<clever>
nice
<clever>
then you could test it in a pure manner, and hydra can keep testing it in the future
<clever>
andi-: it may also be possible to rig up a nixos-test using the existing qemu framework, to spin up a hydra and build slave, with the sortaSlow derivation as a job
<clever>
andi-: though i currently lack access to the hydra i reproduced it on, the power blipped at home, and that box never came back online
<clever>
andi-: its just things like builder@amd.localnet x86_64-linux /root/.ssh/nix 8 1
<clever>
andi-: nope, one sec
<clever>
arianvp: you can rig it up so ssh shares a single tcp socket (and auth session) between many ssh shells
<clever>
arianvp: an ssh master connection can also help
<clever>
andi-: that would likely simplify this, lol: [clever@system76:~]$ ssh ext.earthtools.ca -A -t 'ssh c2d -t "screen -xRRU"'
<clever>
arianvp: ah
<clever>
oops, andi-
<clever>
arianvp: which program is that flag for?
<clever>
(until you manually remove them, of course)
<clever>
so you can do fun things like `ssh laptop -A 'ssh-add'` to copy the laptop keys into the gpg-agent, and they stay there, forever
<clever>
ive also noticed, gpg-agent saves all added keys to its internal keyring, and they arent lost at shutdown
<clever>
though i'm using normal secrets in the agent, not PKCS11
<clever>
i also prefer the gpg-agent for ssh
<clever>
are there any obvious errors if you strace both the ssh-agent process and the ssh-add proc?
<clever>
i see
<clever>
ah
<clever>
arianvp: that action would likely require copying the secret out of the yubikey and into the ssh-agent, and then all security is gone and somebody could just clone the yubikey
<clever>
bbl
<clever>
hyper_ch: it can re-sync the hardware-configuration.nix with the currently mounted FS's
<clever>
hyper_ch: because nixos-generate-config will overwrite hardware-configuration.nix
<clever>
hyper_ch: i'm guessing you just set the fsType = "bind";
<clever>
hyper_ch: both files use the identical syntax
<clever>
hyper_ch: the same as in hardware-configuration
<clever>
hyper_ch: but you probably want to do it in configuration.nix
<clever>
pie_: do the naughty and just edit the nix store? lol, and then later `nix-store --verify --check-contents --repair` to fix it
<clever>
pie_: that will build something in /mnt/nix/store and deal with all the chroots for you
<clever>
catern: youll need to set users.users.root.initialPassword
<clever>
catern: it has no default login password
<clever>
catern: that script was to make qemu emulate a system with or without nvme, and/or uefi
<clever>
haitlah: you could also just `nix copy --all` to upload the entire store
<clever>
haitlah: you need t know what derivations you want in the cache, and upload them there, and its tricky to know what was compile-time only, which is where hydra helps out
<clever>
that is what tells nixos what to include in the initrd
<clever>
catern: eval the config.boot.initrd.availableKernelModules attr
<clever>
that can work, as long as you know what all is needed
<clever>
then you change the kernel, and they cant load...
<clever>
catern: and those modules are baked into the initrd it builds
<clever>
catern: one tricky part though, is that nixos needs a decent number of modules to boot (in qemu-vm.nix for example, it needs 9plan to mount the store)
<clever>
catern: for for the kernel, youll have to mess with line 109 in that file
<clever>
catern: if your configuration.nix has virtualisation.graphics = false; then it will link stdio to the serial port
<clever>
catern: build-vm just tells nixos-rebuild to build a certain attr of <nixpkgs/nixos>
<clever>
catern: have you seen nixos-rebuild build-vm?
<clever>
ah
<clever>
Lisanna: not-os is one example
<clever>
Lisanna: you are able to just run the module framework against non-nixos things
<clever>
arianvp: i havent looked into the yarnNix attribute yet
<clever>
ah
<clever>
arianvp: you would need to run that part manually, and add its result to nixpkgs
<clever>
arianvp: yarn2nix still needs IFD, even with a yarn.lock
<clever>
arianvp: *looks*
<clever>
arianvp: sure
<clever>
yeah
<clever>
if outputHashMode="recursive" then $out can be a dir, and its a hash over the NAR of that dir
<clever>
if outputHashMode="flat"; then $out must be a single file, and outputHash is its hash
<clever>
gleber_: then the $out will depend entirely on those 3 attrs, and the name attr
<clever>
gleber_: if you define the 3 above attrs, any derivation can become fixed-output
<clever>
gleber_: define a derivation with an, outputHashAlgo, outputHash, and outputHashMode ("flat" or "recursive")
<clever>
gleber_: fixed-output derivations can do that
<clever>
gleber_: so the derivation still has a system set on it, but its declaring that the linux and darwin builds have identical output, and it can mix&match them via the binary cache
<clever>
gleber_: and system is just set to whatever pkgs its currently in
<clever>
gleber_: all it really does is define the output hash, the same as fetchurl
<clever>
gleber_: there is a font derivation in nixpkgs that does that