2020-05-02

<clever> then it should just be automatic
<clever> dxtr: either `boot.supportedFilesystems = [ "nfs" ];` or set the fsType of something in fileSystems.foo to "nfs"
<clever> dxtr: did you enable nfs client support?
<clever> whyuk: you could also try the tar tooling instead
<clever> whyuk: and storeContents can just be a list containing config.system.build.toplevel
<clever> whyuk: line 18 will generate a directory containing info about a list of store paths, 22 will generate the db.sqlite backup, and 25 will read the list of paths the backup describes
<clever> whyuk: lines 18 and 22 of make-squashfs.nix
<clever> if you nix-build this file, you get a dir with a kernel, initrd, and a partial grub config file
<clever> whyuk: the entire rootfs.squash is held within the initrd, so you dont need any special logic to find it
<clever> whyuk: this uses the netboot images nixos already contains
<clever> whyuk: ah, do you want the squashfs to live entirely in ram (usb can be unplugged after boot), or live on the usb?
<clever> whyuk: what are you doing with that squashfs boot?
<clever> whyuk: the squashfs tooling in nixpkgs already made the backup, you just need to import it like this
<clever> whyuk: ah, you need to import a backup of db.sqlite on the first boot
<clever> whyuk: is this a new install? how did things get like this?
<clever> whyuk: yeah, definitely sounsd like the path is missing from db.sqlite
<clever> whyuk: what happens if you `nix-store -qR /run/current-system` ?
<clever> vancz: any currently running binary is rooted, via /proc voodoo
<clever> whyuk: it sounds like the current generation isnt even in db.sqlite
<clever> energizer: so you have to embed a storepath into the output
<clever> energizer: your runtime dependencies is whatever your refering to in $out when the build is done
<clever> Wulfsta: was probably cole-h
<clever> Raito_Bezarius: not sure, but he is on irc, and its about noon for him
<clever> Raito_Bezarius: i dont know how, but craige is doing something like that
<clever> energizer: it doesnt propagate to runtime
<clever> energizer: propagatedBuildInputs only propagates to the build-time of other things that depend on your pkg
<clever> romanandreg: the kernel is usually managed by the distro's package manager
<clever> romanandreg: the drivers have to match the kernel version, which means you have to be running a kernel from nix as well

2020-05-01

<clever> Fare: it should just respect $CC, and then the makefile can provide a default when its missing
<clever> > gccStdenv.mkDerivation
<clever> Fare: or use gccStdenv to get a real gcc
<clever> Fare: use $CC and $CXX to get the compiler
<clever> Fare: thats what wrapProgram is for, to prepend things to PATH before the thing gets ran
<clever> it will look in $PATH
<clever> Fare: `#!/usr/bin/env foo` will work just fine outside of nixos as well
<clever> Fare: you should just run "gsc" directly, let $PATH do its job
<clever> Fare: use #!/usr/bin/env foo, but then run patchShebangs on the directory if its ran at build-time
<clever> Fare: what are you doing with env?, a #! line? running it? at build or runtime?
<clever> then if its in buildInputs, it gets found
<clever> Fare: then it will just find it from $PATH, and hard-code that into things
<clever> Fare: modify the Makefile to just do `-DFOO_PATH=$(which foo)`
<clever> Fare: you could even make it 100% automatic
<clever> adisbladis: it was mostly the bare min needed to make the whole stack work
<clever> Fare: then the Makefile can decide between a default, or a value in makeFlags
<clever> Fare: for example, compile something with -DFOO_PATH=${FOO_PATH}
<clever> Fare: modify the build system to allow env vars to do that at build time
<clever> Fare: why do you need those patches you cant upstream?
<clever> energizer: and if your targeting something you lack the source for, you also need unpackPhase and patchPhase
<clever> energizer: configurePhase and buildPhase are still of use during development
<clever> energizer: all functions the stdenv adds, buildPhase, installPhase, unpackPhase, unpackFile ....
<clever> energizer: the main thing is bash functions
<clever> Fare: overlays
<clever> thats what setup hooks are for
<clever> Fare: just put those libraries into the buildInputs list in your shell.nix file, done
<clever> the whole point of nix-shell, is to do impure builds in an interactive manner
<clever> nix-shell is impure by default
<clever> yeah
<clever> Fare: run nix-shell, then run the IDE cmd
<clever> Fare: why do you have to reproduce the IDE under nix-shell?
<clever> Fare: then run the IDE under nix-shell
<clever> Fare: even basic gcc use wont work right if your outside of nix-shell
<clever> energizer: that just extracts the env vars from nix-shell, and sets them in your shell
<clever> Fare: enless you want to re-engineer a lot of stuff, its recommended you just run nix-shell as normal
<clever> Fare: development stuff is only meant to work inside nix-shell
<clever> codygman__: ah, its --ignore-liveness not --force
<clever> Avaq: configuration.nix doesnt return a set containing pkgs
<clever> codygman__: that would blow away everything in the nix-env profile
<clever> codygman__: meant `nix-store --delete --force`
<clever> codygman__: then you can just reinstall home-manager from scratch
<clever> codygman__: if the only root is your nix-env profile, then you can use `--delete --force` and it will just blow away the entire nix-env profile
<clever> codygman__: is there only one generation of nix-env's profile?
<clever> ah
<clever> adisbladis: which thing? ive linked a lot of iohk things, heh
<clever> cab404[m]: irc doesnt support pinned messages
<clever> Fare: 2020-05-01 17:31:35 < adisbladis> I got inspired and hacked up http://ix.io/2knm
<clever> codygman__: `nix-store -q --roots`
<clever> Fare: the expr adisbladis linked above i believe
<clever> codygman__: you need to delete that home-manager path, using the same `nix-store --delete`
<clever> codygman__: that cmd fails, because /nix/store/rjfvyfc4k8rw5kyjcc6lxg2vs1jr5c90-home-manager-20.03 is also corrupt
<clever> codygman__: for env-manifest.nix, all you can do is a rollback against whatever profile its in
<clever> codygman__: next time you eval the expr that created it, nix will restore the file
<clever> codygman__: drv files cant be repaired, all you can do is delete them with `nix-store --delete`, dont use the force flag
<clever> adisbladis: do you know much about the cross-compile stuff in nixpkgs?
<clever> adisbladis: then the devs went and rewrote it using 6 seperate docker containers and a docker compose :P
<clever> i went a little nuts with it, lol
<clever> adisbladis: so with this image, you get nginx, oauth2_proxy, grafana, prometheus, and several iohk products
<clever> adisbladis: also, this runs nixos services, under runit
<clever> but i prefered to have a pure nix build remain intact
<clever> adisbladis: for reasons, this had to support building from a DockerFile as well
<clever> dont use force
<clever> Fare: run `nix-store --delete` on each one you can find in /nix/store/
<clever> adisbladis: already done...
<clever> Fare: but does your docker image need the postgres enabled version?
<clever> Fare: do you need postgres?
<clever> (when used against the writeText from before)
<clever> Fare: this tells me that postgresql depends on systemd!
<clever> $ nix why-depends ./result /nix/store/xdmdlw4m1ad99xm6y5wrmx655iadfza7-systemd-243
<clever> Fare: gcc is 134mb, python is another 58mb, systemd is in there and could be removed
<clever> Fare: let me ignore zfs comp....
<clever> adisbladis: yeah
<clever> which is 774mb after decompression
<clever> Fare: this produces a 222mb gzip'd docker image
<clever> $ nix-build -E 'with import <nixpkgs>{}; dockerTools.buildImage { name = "name"; contents = [ gerbil-unstable gambit-unstable gcc bash coreutils zsh openssh su screen nix ] ++ pkgs.gerbil-unstable.buildInputs; }' --option builders ''
<clever> adisbladis: the typical thing is to just run adduser, but that requires the runAsRoot thing, which uses qemu+kvm and harms build perf
<clever> 382mb here, counting zfs compression
<clever> $ nix-build -E 'with import <nixpkgs>{}; writeText "name" "${toString ([ gerbil-unstable gambit-unstable gcc bash coreutils zsh openssh su screen nix ] ++ pkgs.gerbil-unstable.buildInputs)}"'
<clever> Fare: you have to include nix in the list if you want nix in the docker image
<clever> that should show everything that gets included into the docker image, sorted by size
<clever> Fare: then run `du -hc --max=0 $(nix-store -qR result) | sort -h` on the result of building that writeText
<clever> Fare: use pkgs.writeText to create a file that contains every storepath you told nix to put into the docker image (you can just "${toString [ the list ]}")
<clever> colemickens: you can also just `-I nixpkgs=/tmp/nixpkgs-pr` instead
<clever> morgrimm: can you pastebin the full error and the nix files you are using?
<clever> niso: correct
<clever> fresheyeball: /var/spool/nginx/logs/
<clever> niso: the error is further up
<clever> niso: Could not resolve SDK product version for 'macosx'.
<clever> turlando: systemd can sandbox services automatically for you
<clever> and this is the code for cabal-merger (turns many cabal files into one) and also cabal-to-snack (creates a nix file that snack can use)
<clever> i never finished things, and just kind of abandoned it
<clever> yeah
<clever> this is the fork where i did the overhaul to fix performance
<clever> infinisil: yeah, it also depends on the scale of the package
<clever> turlando: but nix will automaticall sandbox things at build-time for you
<clever> turlando: if you want to sandbox things at runtime, yes
<clever> infinisil: which has to re-hash the build directions for Foo.Bar, and everythng it depends on, recursively
<clever> infinisil: basically, every time you import Foo.Bar, it re-runs stdenv.mkDerivation for generating Foo.Bar
<clever> infinisil: lack of memoization
<clever> in that 48 hours, i was able to rewrite half of snack, to make it eval in 15mins
<clever> just the nix eval alone
<clever> it took over 48 hours just to eval cardano-sl with snack :P
<clever> i wrote a cabal-merger to undo that, and put it all back into 1 cabal file
<clever> so if your project has 2 or more cabal files, things already start to fall apart
<clever> and uses plain cabal2nix for all deps
<clever> infinisil: it has several issues, 1st one is that it can only do module level building for the final cabal file
<clever> turlando: it should work just fine once you map /nix to that namespace
<clever> turlando: yeah, thats one option
<clever> ah, ive not messed with them much yet
<clever> `pkgsCross.musl64.pkgsStatic.nix` should combine both static and musl
<clever> which tends to be larger
<clever> thats static with glibc
<clever> cross-compile with x86-64 musl, instead of glibc
<clever> try that last one
<clever> ah, so it was a dynamic musl
<clever> > pkgsCross.musl64.pkgsStatic.nix
<clever> jakobrs: which interpreter?
<clever> jakobrs: i think that will be static
<clever> > pkgsCross.musl64.nix
<clever> jakobrs: the nix.buildMachines nixos option, then generates that
<clever> jakobrs: which is described in the nix manual
<clever> jakobrs: the file at /etc/nix/machines
<clever> jakobrs: line 453 is what converts it, and should be throwing errors for unknown keys
<clever> jakobrs: thats not a valid option
<clever> jakobrs: and the example just above that
<clever> fileSystems and swapDevices are both submodule based, last i looked
<clever> i think submodules are still allowed
<clever> submodule would be better, so it typechecks those sets
<clever> jakobrs: which complicates setting the env var to make it talk to ssh-agent
<clever> jakobrs: for multi-user nix, the nix-daemon running under systemd is doing the ssh normally
<clever> jakobrs: depends on if its single or multi-user nix
<clever> yeah
<clever> jakobrs: its calling `nix-store --serve`, which opens a binary bi-directional protocol
<clever> shell?
<clever> jakobrs: then issues a build of a .drv file remotely, waits, and copies store-paths back out
<clever> jakobrs: it runs `nix-store --serve` over ssh, then uses that to push storepaths and drv's over
<clever> but i think --store daemon?something=/path/to can point you to a diff socket, and then socat
<clever> jakobrs: that usually happens over ssh
<clever> pkgs.runCommand can simplify doing it manually though
<clever> ToxicFrog: dont think theres anything like that really
<clever> ToxicFrog: so you can just copy normally, then have nix dedup the whole store
<clever> ToxicFrog: `nix-store --optimize` will create the hardlinks after the build has finished
<clever> of note, the limit is for the sum of both argv and all env vars
<clever> that shows the actual limits, for your system
<clever> Cadey: `xargs --show-limits`
<clever> Cadey: the fact that its 3000 lines long, could be the problem, lol
<clever> that one is part of bash, so it doesnt need to fork
<clever> Cadey: try `set` then
<clever> elux: you have to go all the way back to something with root (sshd, the login screen) for the changes to apply
<clever> elux: the terminal inherits the groups from the window manager, which has the same problem
<clever> elux: changes to your groups dont take effect until you logout and back in
<clever> elux: what does `id` report?
<clever> asbachb: ahh, split outputs, dev wasnt picked up automatically
<clever> nix-shell -p 'linuxPackages.turbostat.overrideAttrs (_: { buildInputs = [ libcap_progs.dev ]; })'
<clever> asbachb: yep, it fails if i use nixpkgs master
<clever> asbachb: so i didnt actually fix the problem
<clever> asbachb: oh, it might be that my nixpkgs is old enough to not be broken yet
<clever> and adding it here, would fix it for good
<clever> that would temporarily fix it
<clever> $ nix-shell -p 'linuxPackages.turbostat.overrideAttrs (_: { buildInputs = [ libcap_progs ]; })'
<clever> yeah
<clever> and what i said, is the fix
<clever> asbachb: or perhaps its already broken...
<clever> asbachb: did you add libcap_progs to buildInputs ?
<clever> libcap_progs.dev 3,297 r /nix/store/fczfcxq7kab59ki9ijfknd0cix472j43-libcap-2.25-dev/include/sys/capability.h
<clever> $ nix-locate capability.h
<clever> eoli3n_: nope, things are pre-built by hydra.nixos.org, and only that can upload to cache.nixos.org
<clever> jakobrs: ive found both single and multiuser tend to not put nix in PATH for non-interactive ssh
<clever> jakobrs: ah, dont think so, your better off fixing the .bashrc on the remote box
<clever> jakobrs: set which path?
<clever> jakobrs: ive not found any proper documentation, so i just searched my irc logs for every single use of it, gathered them into one gist (linked above), and then began figuring out what they do
<clever> and then that causes the remote nix to prefix all things with /mnt/
<clever> jakobrs: this will tell the remote nix (after the ssh) to open the store of `local?root=/mnt`
<clever> Raw
<clever> nix copy --to ssh://root@target?remote-store=local?root=/mnt /nix/store/hash-nixos
<clever> ive modified it some
<clever> jakobrs: the one in nix-bundle has a few extra features
<clever> jakobrs: NIX_REMOTE=local?root= also has other fun uses
<clever> jakobrs: but you can now use this to chroot without root
<clever> and chroot needs root
<clever> i didnt know how namespacing worked when i wrote that
<clever> they can also be combined, if you lack access to that wonky dir, on the build machine
<clever> jakobrs: NIX_STORE, NIX_LOG_DIR, NIX_CONF_DIR, NIX_STATE_DIR is if you want it to actually run from that wonky dir, without any chroot
<clever> jakobrs: NIX_REMOTE=local?root= is if you want to relocate the /nix/store, but you plan to chroot later, and the paths should still think its at /nix/store
<clever> jakobrs: chroot/namespacing would be much simpler
<clever> jakobrs: so you can then copy /home/clever/rootfs/home/example/nix to /home/example/nix of a remote box, and the resulting nix binary will just work
<clever> jakobrs: and then the override to nix within the -E, makes the 1st half permanent within the copy of nix its building
<clever> jakobrs: NIX_REMOTE=local?root=/home/clever/rootfs then prepends that to the paths, so the store ACTUALLY winds up at /home/clever/rootfs/home/example/nix, and the internal strings expect it to be at /home/example/nix
<clever> jakobrs: NIX_STORE, NIX_LOG_DIR, NIX_CONF_DIR, NIX_STATE_DIR all work together, to put the store at /home/example/nix
<clever> jakobrs: yes, one min
<clever> weird
<clever> jakobrs: did you boot via legacy or efi? efi cant chainload legacy
<clever> but mine is legacy based
<clever> jakobrs: yep
<clever> jakobrs: i just manually wrote such a grub entry
<clever> if i run it with zero args, it does pick up the win7 nearby
<clever> /dev/sdc1:Windows 7:Windows:chain
<clever> [root@amd-nixos:~]# os-prober
<clever> Setzer22_2: i believe for uefi, you just give linux its own fat32 /boot, and then both OS's will show up in the bios's menu
<clever> Setzer22_2: is windows booting with uefi or legacy?
<clever> adisbladis: `NIX_SSHOPTS="sudo"` would only work if your not using ah ssh master socker and not using -v
<clever> adisbladis: you may need to patch the client-side nix, to support running sudo on the remote machine
<clever> 82 conn->sshConn = master.startCommand("nix-daemon --stdio");
<clever> so we want to insert it around here
<clever> 27 std::unique_ptr<SSHMaster::Connection> SSHMaster::startCommand(const std::string & command)
<clever> 62 args.push_back(command);
<clever> so if you tried doing `NIX_SSHOPTS="sudo" nix-copy-closure` it can potentially break
<clever> adisbladis: yeah, potentially adds -S foo and -v after the $NIX_SSHOPTS
<clever> adisbladis: $NIX_SSHOPTS lets you inject custom arguments into the ssh cmd that nix uses to reach a remote machine...
<clever> adisbladis: checking the src...
<clever> adisbladis: what about using privilegeEscalationCommand with the copy-closure too?
<clever> adisbladis: `nix show-config` would show the result of parsing all cfg files, though it also parses the ones root wont read
<clever> you can use `nix-store --query --roots` to figure out why something cant be deleted
<clever> but dont use --delete --force
<clever> foineoi: unpackPhase copies the source to ., patchPhase must then modify the copy in .

2020-04-30

<clever> ah
<clever> jlv: what does `nix-channel --list` show, for both your user, and root?
<clever> jlv: i think one is for the channel called nixos, the other is the alias that lets <nixpkgs> map to nixos
<clever> romildo: i also dont see it in there
<clever> romildo: i'm a bit surprised that scim isnt already in nixpkgs
<clever> niso: yeah, that sounds like a good area
<clever> jlv: but you may want to batch several --add into a single atomic update
<clever> jlv: nix-env and nix search operate on ~/.nix-defexpr/
<clever> jlv: --update then syncs that into your channels profile, which is symlinked under ~/.nix-defexpr/
<clever> jlv: --add and --remove simply update a plaintext file at ~/.nix-channels
<clever> jlv: did you run `nix-channel --update` after removing the channels?
<clever> niso: there is also the script and preStart keys, which can take multiple lines, generate a script with a #!, and then point ExecStart and PreStart to the generated file
<clever> niso: if you set the startAt on a service, then nixos generates a timer for you
<clever> niso: nixos can do it with one
<clever> niso: its usually simpler to use systemd timers instead
<clever> xelxebar: was helping somebody else with rpath issues, x and z are right netx to eachother
<clever> streams*
<clever> niso: vlan 34 dhcp gives an ip somewhere in 10.0.0.0/8, and multicast subscriptions give RTP sreams with tv service
<clever> niso: dhcp on vlan 35 gives my a public ip, and binds the mac of whatever did it to the connection, so no other mac can get a lease until things expire or are released
<clever> niso: and then the mis-configured isp router, connects to that, and double-nat's its way out, lol
<clever> niso: so i then run my own pppoe server, on vlan 35, pointing the wrong way (towards the internet, being ignored)
<clever> niso: but i have then discovered, half the STB features need internet
<clever> hr[m]: you want builtins.toFile "coc-settings.json" (builtins.toJSON (import ./coc.nix))
<clever> hr[m]: you didnt tell nix to import that nix file, so all it did was serialize the string (a path to coc.nix)
<clever> niso: i then use a dumb switch, to put 2 routers on 1 modem, the nixos router handles vlan 35, the isp router handles vlan 34 (tv service)
<clever> niso: so ive intentionally mis-configured the isp router to use pppoe, which breaks its attempts to use dhcp on vlan 35
<clever> niso: i dont know what the isp router is doing to make the iptv setup work, but the isp router is also not reliable for internet usage
<clever> niso: my setup is very wonky
<clever> jumper149: strings in nix also have context, which says which store paths they depend on
<clever> jumper149: if you try to treat a path as a string, nix will automatically copy it into /nix/store
<clever> niso: nope, i just ran nixos on a seperate x86 machine
<clever> jumper149: paths are a special type in nix, always absolute
<clever> niso: there are no login details, you just 802.1q vlan tag, and dhcp your way to the internet
<clever> cole-h: let x = import ./.; in something with x.buildInputs and x.nativeBuildInputs
<clever> cole-h: then you can just (import ./.).buildInputs
<clever> niso: i suspect its a memory leak in the http server
<clever> cole-h: try to eval things from default.nix in nix repl, can you find the buildInputs you wanted?
<clever> cole-h: typically, if there is no funny wrapping going on
<clever> cole-h: nix-shell would give you the derivation that does the build, not actually build it
<clever> cole-h: and perhaps apply overrides to what it imported
<clever> cole-h: shell.nix should just `import ./default.nix`
<clever> niso: my ISP router will lock up hard (zero packets pass) if you poll an http page, and it crashes like clockwork, 29.5 days of uptime i believe