<clever>
ive also seen somebody use that for their desktop, the nixpkgs would chain itself from the current generation to all future generations, so its managed in nix, but not nix-channel
<clever>
disasm: so you never have to deal with channels on the servers, the nixpkgs just always matches the current build
<clever>
disasm: the nixops-managed.nix file also messes with $NIX_PATH, pointing it to whatever nixpkgs was used to build the machine
<clever>
michas_: i figured that out just by reading all of the nixos sources
<clever>
then it actually "worked", lol
<clever>
gchristensen: then one day, his new machine did have a configuration.nix
<clever>
gchristensen: and he claimed it has worked before (because they lacked a configuration.nix, and it did nothing)
<clever>
gchristensen: ive also seen somebody in this channel set the auto-upgrade flag in nixos, on nixops managed machines
<clever>
michas_: nixos cheats, by keeping a copy of the generation you originally booted
<clever>
michas_: if you nixos-rebuild switch too far into the future of nixpkgs, the kernel modules cease to be compatible
<clever>
michas_: yeah, it nees to root the booted version, for kernel modules
<clever>
disasm: some nixops images include a dummy configuration.nix, and nixos-rebuild would undo the entire deployment, reverting it back to a fresh state
<clever>
disasm: yeah, thats why i'm considering builtins.fetchGit ./. since it strips out all files git isnt managing
<clever>
michas_: what is the root holding on to it?
<clever>
michas_: ok, then run nix-store --query --roots on the wayland path
<clever>
ottidmes: yeah, those can be tricky, mostly just takes experience to know the flow of things and how to avoid it
<clever>
ottidmes: but with nix, it makes one on every build, and keeps them with the build
<clever>
ottidmes: i also have zfs snapshoting, with snapshots being made monthly,weekly,daily, hourly, and every 15mins
<clever>
michas_: look at nix-store --query --tree /run/current-system, and see what the path is
<clever>
ottidmes: and then if i need to undo something, i have history in the store
<clever>
ottidmes: so i let nix snapshot the entire config on every build
<clever>
ottidmes: more, that i dont want to commit every single 2 line change
<clever>
matt_r_: i recently converted my router from nixos to nixops, and it has made it much simpler to manage
<clever>
ottidmes: the revision wont tell you the changes, and i use that trick to get the smaller iterative stuff i do between commits
<clever>
ottidmes: i have recently considered switching to `builtins.fetchGit ./.` from nix 2.0, which cleans the directory, but .git is also lost, so no more diffs
<clever>
ottidmes: but nix-store --optimize can dedup those copies together
<clever>
ottidmes: nix just clones the whole thing, including all of the .git
<clever>
what hostname is it trying to connect to?, can you gist the output and nix expressions?
<clever>
matt_r_: i recently had to fix something with `nixops deploy --allow-recreate --include HOST -d cluster --check`
<clever>
that should test everything, and re-create anything thats missing
<clever>
another thing you can try, nixops deploy --check
<clever>
ah, thats it
<clever>
matt_r_: do you have deployment.type = "ec2"; ?
<clever>
yeah, its broken that --include can skip dependencies
<clever>
this reports what i had changed when building 356
<clever>
matt_r_: it helps if you keep the nix expressions in git, then you can just `git diff` to see what you did to break it
<clever>
matt_r_: that shouldnt happen
<clever>
matt_r_: what params are you running it with?
<clever>
matt_r_: the parallelism in nixops sometimes gets ahead of itself, and --include forces it to skip creating some times
<clever>
sphalerit: yeah, pushbullet does full instant messaging, both between friends, and your own devices, so i can push a url to the desktop, and it can attach images to those IM's
<clever>
sphalerit: ive been using pushbullet for that lately, does syncthing support similar?
<clever>
gchristensen: i think it waits for a reply from an ELF binary in /tmp to shut itself down for updates, so it just semi-hangs when it tries to update itself
<clever>
gchristensen: last time i used it on nixos, it worked out of the box with a nix-env -iA nixos.dropbox, and as long as i dont let it update, it keeps working
<clever>
and also ive run out of space anyways
<clever>
i should look into that then, ive had trouble with dropbox breaking on nixos because it self-updates
<clever>
i'm used to forcing answers out of unfree software
<clever>
yeah, lol
<clever>
sphalerit: more thinking about how you would decrypt it, to confirm what its doing
<clever>
ottidmes: but burp will need root to listen on 443
<clever>
ottidmes: ah yeah, that works perfectly, and burp supports such modes
<clever>
ive used it before to see what android apps are up to
<clever>
only tricky part is getting syncthing to use it as a proxy
<clever>
ottidmes: using security.pki.certificates you can get the system to globally trust a self-signed cert, which allows you to mitm anything https
<clever>
ottidmes: ah, that will be tricky to inspect then
<clever>
sebboh: the repl says :? for help, and you can just eval config.boot to see the config
<clever>
priority=10
<clever>
mfiano: you can edit the wpa_supplicant.conf after the above cmd, to set a priority
<clever>
sebboh: the man page is auto-generated from the nix expressions
<clever>
mfiano: wpa_gui works on nixos and i think it can write to wpa_supplicant.conf for you
<clever>
sebboh: nix-repl '<nixpkgs/nixos>'
<clever>
pmade: nix.package = pkgs.nixUnstable; to upgrade it
<clever>
mfiano: leave /etc/wpa_supplicant.conf unmanaged by nix, and just manualy copy the file in after the install
<clever>
pmade: builtins.fetchGit ./.
<clever>
deanman: try both?
<clever>
deanman: for channels, it should honor them
<clever>
joko: originalSystem may be {}, but never null
<clever>
phdoerfler_: one-shot systemd units that check for the existance of the resource they create
<clever>
joko: toplevel is a package
<clever>
mfiano: so <nixos/nixpkgs/nixpkgs/nixpkgs> is the same as <nixos>
<clever>
mfiano: <nixos> gives the channel named nixos, and nixpkgs is a symlink to . within that
<clever>
TonyTheLion: and if you have a boot partition, that should be at /mnt/boot/
<clever>
TonyTheLion: while booted into a recovery environment, you need to move the contents of /nix to the new partition, while preserving all ownership bits, then mount the original rootfs to /mnt and the store to /mnt/nix, then `nixos-install --chroot`, fix configuration.nix, and `nixos-rebuild boot`
<clever>
mfiano: nix-repl '<nixpkgs/nixos>'
<clever>
TonyTheLion: i have changed it after install, but you need enough free space to make the partition, and you have to move the data over while booted into a recovery mode
<clever>
TonyTheLion: thats also something you usually can only change at install time
<clever>
TonyTheLion: if your using nixos, you have to set fileSystems."/nix" = { ... to configure it to mount on bootup
<clever>
TonyTheLion: i always put /nix on its own zfs dataset
<clever>
the_real_plumps: your welcome :)
<clever>
the_real_plumps: bienvenue
<clever>
the_real_plumps: set nix.package = pkgs.nixUnstable; in configuration.nix
<clever>
the_real_plumps: yeah, that "release" is a bit confusing
<clever>
matt_r_: ssh should just come up on its own
<clever>
nix-env -e nix
<clever>
you installed the unstable one with nix-env, and now its having a small conflict
<clever>
yep
<clever>
without the realpath
<clever>
the_real_plumps: where is nix-build?
<clever>
what about just which nix-build?
<clever>
thats 1.12, the pre-release of 2.0
<clever>
the_real_plumps: what does this say: realpath $(which nix-build)
<clever>
the_real_plumps: your using 2.0 features with a 1.11 daemon
<clever>
{ resources, ... }:
<clever>
the deployment accepts a resources parameter
<clever>
so it has to boot linux, unlock, then kexec linux (or soft reboot)
<clever>
samueldr: when the drive is encrypted, all you can see is a special shadow partition, which will boot using this image, if you then run a special sedutil, the drive unlocks, and then you can only see the protected content, and the shadow is missing
<clever>
ive used it with both u-boot and pxelinux
<clever>
yeah
<clever>
shlevy: but if you ssh in, it stops the count-down, and you can pick which generation to kexec into, or just get a shell
<clever>
shlevy: the bootloader, is a linux kernel+initrd, that runs something like dropbear, and waits 30-60 seconds, then it will kexec the default option
<clever>
shlevy: ive had an idea ive been wanting to write for a while, a dropbear based bootloader
<clever>
neat
<clever>
snajpa: nixos has been mounting /nix/store over /nix/store for ages, to make it read-only
<clever>
though i have made a custom character device in the kernel itself, it implements a sub-section of the handlers
<clever>
ive only felt with the filesystem api via fuse, for the most part
<clever>
Mic92: i *think* that the readdir/open syscalls on the root directory can know that, but they would then have to propagate it via special handles to the subdirectories?
<clever>
then you have proper length prefixed strings and multiple channels
<clever>
launch your haskell program inside the guest, and setup a muxed channel over the serial port
<clever>
what if you want to run 2 things in parallel?
<clever>
what happens if the command happens to print an EOF?
<clever>
srk: it just runs the command, echo's the return code, then prints EOF
<clever>
Mic92: up one level, in the project itself
<clever>
and .jobsets also leaks some of the info on where to find that declarative config
<clever>
if its declarative, it will always have .jobsets
<clever>
Mic92: open the hydra itself, and look for a jobset called .jobsets
<clever>
youll need to share something then, and put the ssh agent socket there
<clever>
and i think my trick relies on /tmp being shared
<clever>
viric: the env vars are cleared
<clever>
viric: if you run strace on the ssh agent, do you see a connection coming in?
<clever>
Baughn: also, it refuses to begin a download until all the dependencies of that item are done downloading
<clever>
ottidmes: nix-prefetch-url '<nixpkgs>' -A hello.src
<clever>
ottidmes: nix-prefetch-url also accepts an attr path i believe
<clever>
ottidmes: either nix-prefetch-url first, or use one of the new-ish nix flags, let me find it
<clever>
Baughn: nice
<clever>
so every time the user fixed the hash, it changed
<clever>
also, ive seen a similar problem months ago, there was a timestamp in the 404 page
<clever>
globin_: read its contents, before assuming the hash it gave is valid
<clever>
globin_: a tip, nix leaves the .zip file in the store after the hash check fails
<clever>
ryantm: run "file" on that zip file
<clever>
Baughn: nix.package = pkgs.nixUnstable;
<clever>
Baughn: possibly
<clever>
gchristensen: the store caches a lot of things
<clever>
Baughn: your `lacks a signature` error is because the nix-daemon is too old for the client
<clever>
tnks: and root can already safely do things without talking to the daemon
<clever>
tnks: it uses .lock files in the store to manage most exclusive access
<clever>
Izorkin: ah, that can break a number of things
<clever>
srid: adding it to systemPackages wont recompile anything to use it
<clever>
mfiano: id just skip lvm in that case
<clever>
srid: and as long as the channel is named nixpkgs-unstable in --list, it will be safe to use on nixos, and the above snippet will find it
<clever>
srid: you can do (import <nixpkgs-unstable> {}).glm in your configuration.nix
<clever>
Izorkin: if you can document how to reproduce the issue, sure
<clever>
srid: that is how you break things
<clever>
srid: you must never run nixos from the nixpkgs-unstable channel
<clever>
srid: what does sudo nix-channel --list say?
<clever>
Izorkin: maybe
<clever>
gchristensen: or launch each shell in a unique directory
<clever>
gchristensen: nix-shell breaks that assumption, you have to rm -rf the dir after closing the shell
<clever>
gchristensen: thats a bug in the qt setup hooks, it creates a directory on startup, and assumes it doesnt already exist, because nix starts all builds in a fresh dir
<clever>
Izorkin: how much free ram?, any swap?
<clever>
Izorkin: are you inside a container?
<clever>
srhb: i think it should be type = types.uniq types.attrs;
<clever>
srhb: options occuring later in the sequence overwrite ones earlier, but options absent in the 2nd will let the 1st bleed thru, mixing kernel versions
<clever>
srhb: since it lacks a type, nixos will run mergeAttrs over things
<clever>
viric: with that, you could just namespace yourself into what is essentialy a single-user install like on debian, even if your on nixos
<clever>
and to make it very simple to install/manage
<clever>
viric: basically, i want to use nix-bundle to install nix into ~/nix/, without the normal mass-recompile issues
<clever>
viric: i was actually planning on something today that would happen to solve your issue as well
<clever>
viric: so you then need either some namespace magic (doesnt need root) or nix copy (needs root) to move the binaries into /nix/store
<clever>
viric: nix 2.0 sort of allows that, with the --store stuff, but the resulting products are at the wrong path and cant just be ran
<clever>
viric: ah, yeah, i see the issue
<clever>
viric: and nix will proxy it around to the right user
<clever>
viric: basically, it would work the same as `ssh -A`, the daemon makes a listening unix socket inside the sandbox, and the nix-build process running as a normal user connects to the ssh agent normally