<clever>
drakonis: you might be interested in my rescue-boot.nix file
<clever>
ah
<clever>
exarkun: of which repo?
<clever>
to import the nix file, then import whatever the string refers to
<clever>
exarkun: import then returns that string
<clever>
so you need import (import ./nixpkgs.nix) {}
<clever>
exarkun: fetchTarball returns a string
<clever>
fuzen: you should be able to just do `import ./default.nix` inside `docker.nix`
<clever>
bahamas: yep
<clever>
bahamas: nix-store -r /nix/store/foo --add-root result --indirect, will create a result symlink pointing to it, which prevents it from being GC'd
<clever>
bahamas: nix-copy-closure can be used to copy it between different machines
<clever>
aria: refer to the above conversation with iqubic, its already fixed in nixpkgs master, just need to wait for the channels to update
<clever>
yep
<clever>
nixos-rebuild just makes the new nixpkgs take effect on nixos
<clever>
correct, only nix-channel --update can update the nixpkgs
<clever>
yep
<clever>
yep
<clever>
iqubic: left<->right is time, left is most recent
<clever>
iqubic: i only see one failure, for nixos.ova.x86_64-linux
<clever>
iqubic: because those are from a week ago, and arent important
<clever>
every job on the left side must be green, before the channel will update
<clever>
iqubic: click that link
<clever>
,howoldis iqubic
<clever>
until the tests are all passing
<clever>
iqubic: unstable is the latest version of master, that tests confirm wont brick your machine
<clever>
iqubic: then the fix probably isnt in unstable yet, only master, youll need to wait for it to hit unstable
<clever>
iqubic: what does `nix-channel --list` say?
<clever>
notgne2: have you seen what i did with haskell-init?
<clever>
notgne2: yeah, ewww perl! :D
<clever>
so i would need to patch it into the perl code
<clever>
notgne2: but, i want to wait until post-start has finished, then start things that depended on it
<clever>
notgne2: the main issue i would run into, is that the perl runner script, does pre-start, start, post-start, and stop all for you
<clever>
but that needs a proper language, not bash
<clever>
then when you started x, you run a function pointer, that runs y
<clever>
notgne2: the only way to make it any better, is to generate a dep tree, and fill the nodes with function pointers to initiate starting more things
<clever>
notgne2: inotify can eliminate the need to poll
<clever>
notgne2: another option, is to just create a file when the service is started, then everything just waits in a while loop, until said file exists
<clever>
notgne2: it also relied on things just blocking until it was fully started
<clever>
notgne2: init.d didnt really support concurrent startup, and you just had to number everything so starting things in order worked
<clever>
notgne2: main problem i can forsee, is just making one wait for another, i dont know if runit supports that, so i may need to implement it in bash
<clever>
l33_: the "new" gnome ruined everything for me
<clever>
lucasvo: services have their own PATH, you have to add things to systemd.services.foo.path = [ pkgs.bar ]; to be able to run them
<clever>
simpson: haskell lets you go one step further, and just use forkIO and pure code, rather then child procs!
<clever>
simpson: but if you can jam every binary into a single executable (like busybox), that could be even better (as long as it doesnt harm performance)
<clever>
simpson: i like the idea of keeping things dynamic (so you can share code between binaries), but using patchelf to reduce closure sizes
<clever>
simpson: it will recursively copy the dyn libs, and re-patchelf things, to reduce the closure size
<clever>
simpson: nixos also has some patchelf based utils, when copying binaries into the initrd
<clever>
so you need to bake the modules into the kernel
<clever>
at which point, why even bother making it pure haskell if you have to put c binaries in :P
<clever>
simpson: so you need the modprobe binary (written in c?) to load modules
<clever>
simpson: kernel modules are a pain, because the a lot of the heavy lifting is done by the modprobe binary, not the kernel
<clever>
simpson: its currently a single binary, under 4mb, with zero dynamic libs (muslc)
<clever>
simpson: haskell-init was mostly just an example, to show what you can do with an ultra-minimal init, and using nix to build it all
<clever>
simpson: ah, that would be even simpler!
<clever>
simpson: #osdev is also available
<clever>
simpson: once a basic userland is up, you would need to port nix itself to that kernel, so it can build itself
<clever>
simpson: i think if you want sel4 under nix, you would need to first look into getting the kernel to build with nix, and then booting it under qemu
<clever>
notgne2: currently, i dont have dependencies handled at all, several services fail to start because postgresql hasnt ran yet, but they just auto-restart until things work
<clever>
notgne2: ahh, so your dealing with dependencies in the code, rather then requiring the user to do that
<clever>
i had to write my own deroot binary, then i noticed 3 setuid binaries already in nixpkgs (nix-index :D), and runit already has its own util for just that
<clever>
the pam in nixpkgs lacks @include support, debian patched pam to have @include support, so the sudo in nixpkgs doesnt work in a docker based on ubuntu!!
<clever>
sudo needs valid pam config files, or it wont do anything
<clever>
sudo will reset PATH, even if you tell it not to
<clever>
notgne2: su will reset PATH, even if you tell it not to
<clever>
notgne2: oh yeah, and it turns out, dropping root is a lot harder then it needs to be, lol
<clever>
notgne2: but i ran into 2 bugs when using it, 1st: it doesnt support .User and .PermissionStartOnly, 2nd: it just does $var = "${foo}"; and if your ExecStart contains a ", all hell breaks loose :P
<clever>
notgne2: ah, have you seen the .runner attr?
<clever>
notgne2: and nearly all of those are just running the existing nixos modules, that run the same services on nixos
<clever>
notgne2: i now have a nix expression, that generates a docker image, that runs postgresql, prometheus, grafana, nginx, oauth2_proxy, prometheus-postgres-exporter, and 2 custom services
2019-09-30
<clever>
including multiple services at once
<clever>
notgne2: then i package it all up into a docker image, so i can just run any nixos service
<clever>
notgne2: ive been working on the reverse i think, i translate systemd service definitions (in nixos modules) into very simple scripts, that runit can then run
<clever>
notgne2: if you want udev in the initrd (ethernet if naming), you must put the entire systemd in the initrd, and the package is pretty hefty
<clever>
shyim: so if you didnt clear the cache, it wont recover for multiple days
<clever>
shyim: by default, the positive ttl is in the days
<clever>
nix will automatically remake them, and re-populate from the caches
<clever>
shyim: yep
<clever>
shyim: those files are used to cache what is in the cache
<clever>
/root/.cache/nix/binary-cache-v6.sqlite
<clever>
/nix/var/nix/binary-cache-v3.sqlite
2019-09-29
<clever>
then everything is root
<clever>
ddellacosta: for things like this, i prefer `sudo -i` to drop you into a root shell
<clever>
ddellacosta: sudo only affects the 1st command, the ; runs the 2nd without root
<clever>
ddellacosta: that should work..., what is the exact command you ran?
<clever>
chris__: simplest thing is to just let grep search the whole thing for a common string
<clever>
emily: you can still run iptables manually to mutate things, after nixos has applied its rules, but nixos will undo those changes next time you nixos-rebuild, potentially breaking things
<clever>
chris__: nix.extraOptions
<clever>
chris__: what are the first 3 lines of your nix.conf?
<clever>
fling: unknown
<clever>
yeah
<clever>
emily: i believe so
<clever>
emily: i think 5.2 is fine, if you use the export_kernel_fpu_functions.patch
<clever>
so FPU operations in userland can come up with the wrong answer
<clever>
basically, it doesnt fully restore the FPU flags when context switching
<clever>
pathToConfig="$(nixBuild '<nixpkgs/nixos>' --no-out-link -A system "${extraBuildFlags[@]}")"
<clever>
and thats going to be a slow-down
<clever>
both nix build, and nixos-rebuild are going to eval the nixos exprs
<clever>
2019-09-28 22:25:39 < durka> or I'm just going to put `rebuild() { cd /tmp; nix build -f '<nixpkgs/nixos>' system && sudo nixos-rebuild switch && rm result; }` in my bashrc
<clever>
354 would also need editing, and the related ones
<clever>
nixos-rebuild is already a wrapper script!