<clever>
gchristensen: why install nixos (with a random nixpkgs rev) when nixops is going to deploy a closure that likely is a mass-rebuild?
<clever>
gchristensen: oh, random idea about packet.net and nixops
<clever>
gchristensen: now my karma is binary, lol
<clever>
jasom: your welcome :)
<clever>
jasom: i did the same thing when i ran gentoo
<clever>
gchristensen: that lack of curl, is how i discovered a bug in the adobe flash player
<clever>
jasom: heh, i know what you mean
<clever>
gchristensen: gentoo lets you do crazy things, like not even have a libcurl, anywhre
<clever>
not a 10min job anymore
<clever>
jasom: should be fairly fast to build the kernel on a modern system
<clever>
jasom: gentoo?
<clever>
but i prefer to have the sandbox on 24/7
<clever>
jasom: its used by the sandboxing, which could be disabled
<clever>
the neat thing, is that you can use nix on one box (without root) to build it, in a pure manner, and then copy it to another box (also without root)
<clever>
but you wont have any help from the binary cache
<clever>
and nix will continue to work there
<clever>
you then move the whole /home/clever/rootfs/home/$X to /home/$X on another machine
<clever>
so it creates a /home/clever/rootfs/home/$X/nix/store
<clever>
but also, at the same time, it will chroot into /home/clever/rootfs/ while building that
<clever>
that makes a special build of nix, that expects the store to live in /home/$X/nix/store
<clever>
ottidmes: this is the most complex one of them all
<clever>
but variations can be made for other uses
<clever>
ottidmes: this will setup the system profile, inside a chroot, and cross-compile
<clever>
ottidmes: this is another fun one
<clever>
Raw
<clever>
NIX_REMOTE=local?root=/mnt/img/ nix-env --profile /mnt/img/nix/var/nix/profiles/system --set -f '<nixpkgs/nixos>' -A system -I nixos-config=/mnt/img/etc/nixos/configuration.nix --option system aarch64-linux
<clever>
ottidmes: with some minor tweaks, you could teach nixops about this, and then it can install to a blank hdd
<clever>
boom, your installed
<clever>
ottidmes: then you just chroot in (nixos-enter), and run `/nix/store/hash-nixos/bin/switch-to-configuration boot --install-bootloader`
<clever>
ottidmes: basically, you can boot a nixos livecd, mount the rootfs to /mnt/, then run this to copy a pre-made nixos, directly into /mnt/, over ssh
<clever>
bgamari: a function accepting 2 sets, and returning another set
<clever>
the irc logs for this machine are ~5gig
<clever>
which is why i prefer to host my own kind of thing like that, just run irssi in screen on a server
<clever>
softinio: from this end, all i know of matrix is that its the thing that spams the channel every time the server crashes, and 200 people disocnnect
<clever>
mdash: so if this drive fails, i'm never configuring the bios again
<clever>
mdash: this is also one of those weird machines, where the config for the bios, is a special parittion on the hdd
<clever>
mdash: its also got a 484sx, so it can be difficult to even run some software, due to the lack of an FPU
<clever>
bgamari: lol, the NIC (an ISA card) doesnt even have a netboot rom
<clever>
bgamari: ok, the old dos box is unpacked...
<clever>
i should try that.....
<clever>
i suspect it might even be able to run dos? lol
<clever>
bgamari: this ipxe command makes it remap the 1st legacy hdd, and then chain-load its MBR
<clever>
bgamari: and ipxe is able to re-route the legacy bios routines for reading the hdd, so grub thinks its a local hdd, but its actually iscsi
<clever>
bgamari: when i was netbooting the rpi, it still had /boot/ on an SD card, but later on with the laptop, it had a non-netboot grub, in the MBR of the iscsi image
<clever>
bgamari: mine was originally to netboot an rpi, and i later used it to netboot a laptop as well
<clever>
bgamari: main problem with this, is that it predates the initrd having proper network, so i peek at the static ip config, and bring the network up with `ip`
<clever>
charukiewicz: its a function you run on the haskell package, either in an overlay, or where you refer to it somewhere
<clever>
charukiewicz: pkgs.haskell.lib.justStaticExecutables disables profiling and does a few other helpful things
<clever>
charukiewicz: yep, the .o files it builds are normal outputs, and the .p_o are the same thing with profiling enabled
<clever>
charukiewicz: i'm guessing you want to run pkgs.haskell.lib.justStaticExecutables over it
<clever>
charukiewicz: that design is how you prevent it from building twice, can you pastebin the build log?
<clever>
cbarrett: thats just how nixops is currently designed
<clever>
cbarrett: i would recomend just having a central box that you run nixops on, and maybe have an api to remotely trigger `git pull` and `nixops deploy`
<clever>
cbarrett: the problem with any idea like that, is that if 2 people mess with the state file at the same time, you get merge conflicts, and aws resources can get lost, and never destroyed, running up a bill
<clever>
catern: ahh
<clever>
what does starman's support do?
<clever>
or systemd waits for a connection attempt, then spawns the real daemon, and gives it the listening socket
<clever>
either systemd does accept() always, and launches a new worker for each connection
<clever>
there are also 2 different ways systemd can do that
<clever>
ah
<clever>
what is the feature?
<clever>
ahhh
<clever>
catern: is it not packaged on either end? ive noticed desync between hydra's release.nix and the nixpkgs expression for it before
<clever>
and the env when running those things, is provided by nix-shell
<clever>
so when you try to run `nix-shell foo.nix`, it runs some things (impurely), and then exits
<clever>
i sometimes make shell.nix files, with a shellHook that will just `exit` at the end
<clever>
jonreeve[m]: yeah, under `nix repl '<nixpkgs>'`
<clever>
and then it will copy the products to the remote targets
<clever>
nixops will build everything using normal nix, which can then either be built locally, or with build slaves (if enabled)
<clever>
ikitat: that part of the code is running under bash, so you can just `env ; exit 1` to see the vars
<clever>
yeah
<clever>
ikitat: i think you want to copy a directory full of overlays to $out/overlays, and then set nixpkgs-overlays=/run/current-system/overlays in nix.nixPath
<clever>
,xy
<clever>
Myrl-saki: there is also a --install-bootloader flag i think
<clever>
arq1: the nixos-enter script handles setting up /run/current-system for you
<clever>
it feels like an `or` statement would handle checking the local package first, then checking elsewhere
<clever>
> let a = {}; b = 42; in a.foo or b
<clever>
package.components.sublibs.bar or package.components.library maybe?
<clever>
that sounds pretty much the same
<clever>
and when other parts of foo.cabal refer to bar, as you translate it to nix, you know bar is a sublib, so translate it to foo-bar again
<clever>
so foo.cabal, with a sublibrary called bar, will show up as foo-bar in the nix
<clever>
my first guess is to just namespace things a bit, under the parent library
<clever>
nice
<clever>
lol
<clever>
almost to 100!
<clever>
jasom: `echo kernel.unprivileged_userns_clone=1 > /etc/sysctl.d/nix-user-chroot.conf` will make it persist after a reboot
<clever>
jasom: `sysctl -w kernel.unprivileged_userns_clone=1` will immediately enable it, but is lost at reboot
<clever>
teto: it has its own on/off switch
<clever>
teto: python packages all use the installCheckPhase, which runs the tests after `make install`