<clever>
immae: that "wrong" ld.so, starts its search in the wrong dir
<clever>
immae: and its using the ld.so from ldd's package, not the ld.so your binary wanted
<clever>
immae: ldd just runs ld.so with a special env var set
<clever>
betaboon: yeah, thats about the only way to avoid having to hold the entire image in ram
<clever>
betaboon: put the rootfs on iscsi instead of embeding into the initrd
<clever>
`_: not sure then
<clever>
`_: your likely using the xterm window manager, there is a nixos option to disable that, which will switch you to another one
<clever>
balsoft: i'm also running custom firmware in the bootcode.bin as well
<clever>
energizer: nixops has some internal stuff, to turn a hashmap into a set
<clever>
energizer: rnix is also a thing
<clever>
pjt_014: personally, i use hydra to do similar, it roots the entire build-time closure
<clever>
pjt_014: lorri might do that, you can also just run `nix-store -r /nix/store/foo --add-root result-1 --indirect` to make a root for any given path
<clever>
atemu12[m]: if bash cant execute something, it just blindly assumes its a bash script, and runs itself on that file
<clever>
atemu12[m]: nope
<clever>
balsoft: but i have recently discovered, that half the #! scripts are using the x86 bash, and yet it somehow still boots
<clever>
balsoft: ive been cross-compiling an entire nixos and deploying it with nixops
<clever>
pjt_014: what expr are you using and how is it failing?
<clever>
keithy[m]: thats why everybody just uses static lists, and only if you decide to edit the cfg, will things change
<clever>
keithy[m]: yep, that will silently ignore any file that doesnt exist
<clever>
nix-repl> :p a
<clever>
[ /home/clever/.bash_history ]
<clever>
if a file is missing both config and options, it gets wrapped with a config = { ... }; automatically
<clever>
then merge the .config and .options of everything together
<clever>
then recursively repeat on every file in imports
<clever>
read the imports list
<clever>
the module system will then run the function to get access to the set within
<clever>
a module is something in the form of `{ config, pkgs, ... }: { config = { something; }; options = { something; }; imports = [ something ]; }`
<clever>
keithy[m]: the config and options returned by every module gets merged, and then the merged result is passed as input back into every module
<clever>
keithy[m]: the imports list is part of the module system, it will recursively load every file in the imports list, then fix-point them all together
<clever>
keithy[m]: the import function takes a single path, parses the nix within, and returns whatever expr is within
<clever>
devalot: then you just flag your service as depending on that one
<clever>
devalot: nixops creates a -keys service automatically, you should see it in /etc/systemd/system and the nixops docs
<clever>
lib.overrideDerivation is the old way of doing it
<clever>
morgrimm: you can usually just use pkgs.foo.overrideAttrs now
<clever>
morgrimm: ah, the override is gone now, youd have to check its git history
<clever>
morgrimm: you can override it as well, look at toxvpn/default.nix in nixpkgs
<clever>
betaboon: probably
<clever>
betaboon: meta = old.meta // { platforms = old.meta.platforms ++ [ more ]; };
<clever>
evanjs: ive not seen it before
<clever>
evanjs: its cache.nixos.org
<clever>
nopsled: nix-build with --dry-run and see if its in the list of things to download
<clever>
betaboon: and it may need both the 397 and 442 at the same time, so thats 839mb needed, plus some overhead and your getting close
<clever>
danderson: though for group stuff, you can just chgrp the socket, and use normal unix permissions to allow/deny connection, seperate from querying the uid
<clever>
betaboon: that 397mb initrd is compressed, if you `cat initrd | gunzip > temp ; ls -lh temp`, how big does it inflate to?
<clever>
betaboon: might not fit after you uncompress, can you give it more ram?
<clever>
betaboon: how much ram? how big is the initrd?
<clever>
nopsled: update-users-groups.pl generates it
<clever>
nopsled: weird, thats not json, just a plain list of names
<clever>
nopsled: that is normal
<clever>
nopsled: how big is the corrupt uid-map, what does `hexdump -C` say about it?
<clever>
nopsled: did you include any unicode characters in any usernames?
<clever>
ivegotasthma: what does `nix-instantiate --find-file nixpkgs` return?
<clever>
ivegotasthma: nixos-unstable last updated 11 days ago, and you want `sudo -i` not `sudo su`
<clever>
matthewcroughan: and nix will then query all substituters, to see what paths are pre-built, and what it has to build locally
<clever>
matthewcroughan: the configuration.nix is parsed to generate build directions for store paths, like /nix/store/0iwz12wb5vfv6mdr2mzgy34r8s7lrz90-nixos-system-amd-nixos-20.03pre202088.e89b21504f3
<clever>
matthewcroughan: it will let you add storepaths into /nix/store/
<clever>
matthewcroughan: so you could setup a server on the other side of the gap, to host the things
<clever>
matthewcroughan: you can then either --from back from it, or host that directory over plain http, and do `--option substituters http://that.server`
<clever>
matthewcroughan: this one creates a directory of .narinfo and .nar.xz files
<clever>
matthewcroughan: there is also another version, let me confirm the cmd...
<clever>
matthewcroughan: then `nix copy --from local?root=mnt /nix/store/something` to copy it back out into the host /nix/store on the other side
<clever>
matthewcroughan: so `/mnt` could be a usb stick you carry over the airgap
<clever>
matthewcroughan: but you can also use `nix copy --to local?root=/mnt /nix/store/something` to create a `/mnt/nix/store/something` dir
<clever>
matthewcroughan: `nix-copy-closure` uses ssh to copy things between 2 machines
<clever>
matthewcroughan: and you can download one of those store paths from a binary cache, or use nix-copy-closure to copy them between machins
<clever>
matthewcroughan: each directory in /nix/store/ is the result of building a derivation
<clever>
matthewcroughan: x86? arm? linux? mac?
<clever>
matthewcroughan: which tar it downloads, is detected at runtime, based on your os and cpu
<clever>
matthewcroughan: the nix install script download a tar file that has a minimal copy of /nix/store/
<clever>
matthewcroughan: but you can use `nix-copy-closure` to copy paths between different machines, or run your own binary cache on the other side of the airgap
<clever>
matthewcroughan: if your offline, you cant download any new paths
<clever>
matthewcroughan: if you pre-download the dependencies for something, you can keep building stuff while offline
<clever>
matthewcroughan: it would still work, it searches the copy of nixpkgs you have locally
<clever>
matthewcroughan: the `nix` command doesnt have any docs yet, just `nix --help`
<clever>
keithy[m]: if its in a string of bash, "source ${./foo.sh}"
<clever>
keithy[m]: ./foo.sh, done
<clever>
matthewcroughan: `nix search`
<clever>
matthewcroughan: if you want to search, `nix search`
<clever>
matthewcroughan: if you want htop, build htop
<clever>
matthewcroughan: nix-build '<nixpkgs>' -A htop
<clever>
keithy[m]: do you want the position of the script, or the nix expr that defines the script?
<clever>
keithy[m]: at parse time, that is turned into an absolute path, based on the dir the file was in
<clever>
keithy[m]: just use ./. in an expression
<clever>
simpson: the hash in /nix/store/hash-name is truncated
<clever>
mpiechotka: you can re-run nixos-generate-config to update hardware-configuration.nix
<clever>
ldlework: what does the backtrace in gdb say?
<clever>
energizer: and the devs are naughty and changed the file on us
<clever>
energizer: upstream could have changed things after it got in
<clever>
and its now 5am here, i should get to bed
<clever>
ldlework: ah, probably not the arch, its listing 2 libasound_module_pcm_pulse.so's because its trying both the 64bit and 32bit ones
<clever>
ldlework: is sunvox a 32bit or 64bit binary?
<clever>
ldlework: ive not updated my channel in a few months
<clever>
awepfijas: lines 12 and 16 tell it what IP to ssh into when you deploy, nas.nix and router.nix then function the same way as the configuration.nix youve been building manually
<clever>
awepfijas: and if your managing baremetal machines (or stuff manually provisioned elsehwere), your foo.nix can be this simple
<clever>
awepfijas: but if you do `nixops modify -d name foo.nix -I nixpkgs=something`, it gets saved into the nixops state file, and will affect all future deployments
<clever>
awepfijas: currently, that includes an `import <nixpkgs>`, so you would need to `-I nixpkgs=something`
<clever>
balsoft: the nix-env step is mostly just to stop garbage collection from eating it, the switch is all that is needed to make it the default at boot
<clever>
awepfijas: are you booting with efi or legacy?
<clever>
fps: and lines 93-118 build a bootcode.bin for the rpi, using a vc4 cross-compiler, and line 101 copies the arm build of the chainloader into the right path before building
<clever>
fps: lines 70-84 builds the arm chainloader for arm
<clever>
fps: line 31-38 builds a libcommon.a, for both arm and vc4
<clever>
awepfijas: no need for the realpath there, symlinks will be followed automatically
<clever>
awepfijas: double-check that you have the right fs mounted to /boot/, that kind of issue usually happens if it isnt mounted
<clever>
awepfijas: was /boot mounted when you ran switch?
<clever>
fps: instead, doing `src = ./app;`, it will filter things better, and rebuild less often, only when the contents of app changes
<clever>
fps: but, if that . is the root of your repo, it also includes .git and default.nix, so even doing `git fetch` will change the "source" without changing any source files, and nix will want to build again
<clever>
fps: if you add `src = ./.;` to that file, and run nix-build, it will copy whatever is in ./. to the nix store, and then build from that copy of the source
<clever>
fps: i also try to avoid putting any source in the root dir of the repo, because it complicates `src = ./.;` you will want later
<clever>
fps: then you can just run nix-shell with no args, to get those packages again
<clever>
fps: make a default.nix that contains: with import <nixpkgs> {}; stdenv.mkDerivation { name = "name"; buildInputs = [ long list of packages ]; }
<clever>
keithy[m]: set serviceConfig.User = "something";
<clever>
mpiechotka: then you want mesonFlags = old.mesonFlags ++ [ more flags ];
<clever>
mpiechotka: that should show the modified mesonFlags
<clever>
mpiechotka: you can also run `nix-store --query --deriver /nix/store/97bywhzi2y48h65a3m1lajfvgwqdgygy-mutter-3.34.5` and then run `nix show-derivation` on that drv file
<clever>
mpiechotka: and that version isnt in the binary cache, so its likely your custom one
<clever>
mpiechotka: there is no other version it can see
<clever>
mpiechotka: then gdm should already be using that version directly
<clever>
mpiechotka: only one path?
<clever>
mpiechotka: `nix-store -qR /run/current-system | grep mutter` what does this output?
<clever>
ah
<clever>
ldlework: how is the monitor connected to the gpu?
<clever>
mpiechotka: and /run/current-system/etc/ gets mapped/linked into /etc, where /etc/systemd/system/ then controls which display-managaer.service is used
<clever>
mpiechotka: that then gets symlinked to /run/current-system/
<clever>
mpiechotka: when you boot, the systemConfig= in the bootloader config says where to start
<clever>
ldlework: it looks completely normal to me
<clever>
ldlework: it might be a problem between your GPU and the monitor?
<clever>
ldlework: it worked on the 2nd attempt, i dont see any glitching at all
<clever>
ldlework: connection timed out
<clever>
numkem: though you probably just want `imports = [ ./path1 ./path2 ./path3 ];` and define more options, dont mix them into the args like that
<clever>
> pkgs.which
<clever>
pie_: which is in which
<clever>
mpiechotka: if gdm depends on mutter directly
<clever>
mpiechotka: the overlay should impact gdm too
<clever>
energizer: user doesnt matter that much
<clever>
mpiechotka: typo in my original example, oops