2019-11-30

<clever> betawaffle: yes
<clever> betawaffle: i think the problem, is that apple keeps changing the kernel, and you must use the right libc for your kernel
<clever> coderobe: youll need to figure out which hydra the image was built from, and add that to your binary caches using --option
<clever> apple*
<clever> betawaffle: because the apply libc cant be in the nix store
<clever> betawaffle: it breaks a lot of system libraries
<clever> coderobe: where did you get the image from?
<clever> coderobe: oh, one potential problem, the bootstrap may not have been included in the img, so it cant build anything until it has that
<clever> :S those match up...
<clever> coderobe: and `nix eval nixpkgs.lib.version` ?
<clever> coderobe: what does `ls -l /run/current-system` say?
<clever> coderobe: its trying to build the bootstrap tools, that means that your building the entire stdenv, from scratch
<clever> coderobe: `nixos-rebuild dry-run` ?
<clever> if you nixos-rebuild --dry-run, what does it print?
<clever> coderobe: x is enabled by default in some libs
<clever> coderobe: it probably does need those, because they differ from what you have
<clever> if its built from a different version of nixpkgs, it will have to re-fetch/build everything
<clever> coderobe: the nixpkgs rev might be different
<clever> betawaffle: you could try: chmod -w -R /nix/store/
<clever> blame apple :P
<clever> betawaffle: id just ignore it then, it will probably work itself out
<clever> betawaffle: to start with, try just running nix-store --delete on the problem path, and dont use force
<clever> betawaffle: all files in /nix/store/ should be read-only
<clever> if any are writable, something isnt right
<clever> betawaffle: when doing what?
<clever> karetsu: done!
<clever> ${builtins.readFile ./foo.ovpn}
<clever> auth-user-pass = /foo
<clever> karetsu: config = builtins.toFile "name" ''
<clever> pistache: ah, that sounds perfect, then you can safely use config = ./something.ovpn; safely
<clever> karetsu: ah, then youll want to look into the nixos module, and see how to pass that
<clever> but openvpn may not support that
<clever> and then put the main ovpn file int he store
<clever> the best option, would be if you can tell openvpn to load the pw from another file
<clever> mostly your preference
<clever> while /path/to/config, will copy it into the store, and insert a /nix/store/hash-config into the args of openvpn
<clever> karetsu: "/path/to/config" will just insert that literal string into the args given to openvpn
<clever> karetsu: if you quote the path to the config file, it shouldnt copy, but then the service wont auto-restart when the config is modified
<clever> karetsu: i think those would go into the ovpn file? but that may still get copied to /nix/store and become world-readable
<clever> Gopal-M: systemd.services.docker.path = [ pkgs.something ];
<clever> Gopal-M: that will do it!
<clever> Gopal-M: journalctl -f -u docker.service -n30
<clever> did the journal have any other messages?
<clever> Gopal-M: what did the journal for docker say when it failed with your method?
<clever> i dont think the mkMerge is needed in this case, but i'm not sure
<clever> and forces it to go after other strings
<clever> mkAfter controls what nixos does when multiple modules set extraCommands
<clever> would that help any?
<clever> Gopal-M: you can use mkBefore and mkAfter to control where in the firewall scripts your rules get inserted into the script
<clever> Gopal-M: the problem with both methods, is that if you restart either service, the changes the other has made will get undone
<clever> Gopal-M: does the script you added return a non-zero exit code?
<clever> xidica: nix-prefetch-url --unpack https://github.com/OWNER/REPO/archive/REVISION.tar.gz
<clever> > lib.fakeSha256
<clever> Thra11: nixos will "repair" it the next time you nixos-rebuild or boot
<clever> Thra11: simplest thing that will persist for a while is to just `rm /etc/nix/machines`
<clever> ,tofu
<clever> xidica: either nix-prefetch-url --unpack, or
<clever> gchristensen: try echoing one of l, t, or w to /proc/sysrq-trigger (LTW, incase your fonts arent good)
<clever> gchristensen: oh, have you seen how to backtrace all kernel threads?
<clever> DigitalKiwi: some thread sits at 100% cpu usage
<clever> DigitalKiwi: a kernel bug that happens on some motherboards
<clever> but, you can use the nixos options to solve that
<clever> _module.args.secrets = import secrets.nix; will allow you to do { pkgs, config, secrets, ... }: in any module
<clever> normally, each file would have to load its own copy of secrets.nix
<clever> coderobe: nodes around the middle of the tree would then be groups of stuff, like laptop.nix, that configures laptop specific stuff, and pulls in both core.nix and wifi.nix
<clever> coderobe: something that you usually set on every single machine, like creating your user, configuring timezones
<clever> and at the top, you may want a single node like core.nix, that everything eventually leads to
<clever> at the bottom, you have a different root node for each machine, which may overlap at some nodes
<clever> the way to visualize it, is multiple overlapping tree structures
<clever> so that would have caused infinite recursion
<clever> also, the value of imports cant depend on any config param
<clever> vs what you wanted, which would be: imports = [ ./something.nix ]; networking.hostName = "device1";
<clever> coderobe: your setup will involve just setting imports = [ ./something/device1.nix ];
<clever> then you put either device1.nix or device2.nix into configuration.nix, and device1.nix itself is what sets the hostname
<clever> coderobe: and both of those have imports = [ ./common.nix ];
<clever> coderobe: the simplest way is to create a device1.nix and device2.nix
<clever> the main difference vs what coderobe did, is that i cant test coderobe's config locally, it will fail due to a missing secrets.nix
<clever> if its missing, some non-secret dummy values are used, so CI can still pass
<clever> if secrets.nix (which is in gitignore) exists, that is used
<clever> xidica: all of my nixos modules will import load-secrets.nix, and use attributes within that to get secret data
<clever> this uses both a vc4 and an arm cross-compiler, to generate a working bootcode.bin file
<clever> and i'm currently using 2 cross-compilers at once to do that
<clever> on this end, ive been focusing on custom rpi firmware
<clever> i did some armv6/v7 stuff on the nixos community box at one point
<clever> coderobe: none that i'm aware of
<clever> but i could hook my pi back up, ive been messsing with it lately, and it wouldnt take much to boot
<clever> coderobe: somewhat, my hydra is currently building under qemu-user, but coreutils is failing tests, so a large chunk of it isnt built
<clever> up to a the defined size limit of the image
<clever> yep
<clever> oscarvarto: if the disk is already loaded into virtualbox and you want to keep the contents, just use the normal virtualbox tooling to resize the disk, then use gparted within the guest to expand the partition
<clever> boogiewoogie: this will show you what the bash script is doing
<clever> [root@nas:~]# grep ExecStart /etc/systemd/system/firewall.service
<clever> because `iptables-restore` can atomicly apply the whole thing at once, making it load faster
<clever> something ive wanted to do (but its a major re-design) is to generate output that is compatible with save/restore
<clever> so each `iptables -A` is slower then the previous
<clever> then it can do an atomic swap of which rules it uses
<clever> boogiewoogie: for nixos, its a bash script that just runs iptables -A repeatedly
<clever> and each time it does so, the kernel has to copy the entire list of rules
<clever> any time you want to modify the rules, the kernel must copy the entire rule table, and modify the copy
<clever> the whole set of rules, is kept in an RCU structure
<clever> there are also performance costs from that
<clever> but most modern firewalls just ignore that, wipe the tables, and re-build the rules with normal iptables commands
<clever> and then pipe it to iptables-restore on bootup, so the rules persisted
<clever> in the old days, you where meant to run iptables-save at shutdown, and shove it into a file
<clever> personally, i would use the default targets on 25-27 for such a purpose
<clever> because when you reload the rules, 36 will temporarily not exist
<clever> 33-36 forms the bulk of the firewall rules, with 36 refusing as a default
<clever> so loopback doesnt get firewalled from yourself
<clever> line 33 says to allow any traffic on the lo interface
<clever> boogiewoogie: i find `iptables-save` to be simpler to read, can you pastebin that output?
<clever> yep
<clever> aveltras: nix-collect-garbage would have deleted the file, result in file-not-found
<clever> aveltras: ls -lh ~/.config/systemd/user
<clever> aveltras: nix-store --verify-path /nix/store/jwanxphaf71xidv871np7azhhqgc5raf-unit-emacs.service
<clever> and if you run realpath on it, its still at the same path?
<clever> aveltras: where within home?
<clever> aveltras: find /etc $HOME -mount -name emacs.service
<clever> aveltras: does status say anything?
<clever> $ systemctl --user status pulseaudio.service
<clever> ● pulseaudio.service - Sound Service Loaded: loaded (/nix/store/5sngikdd1ya4dwv4yaybq92y16n0lapg-pulseaudio-13.0/lib/systemd/user/pulseaudio.service; indirect; vendor preset: enabled)
<clever> dansho: that implies that the binaries where not compiled with the right RPATH entries, and something else is wrong
<clever> superbaloo: https://github.com/cleverca22/rpi-open-firmware/blob/master/default.nix#L4-L5 is a recent example i just wrote
<clever> superbaloo: when cross-compiling, you must run nix-shell on a cross stdenv, mkShell likely uses a native stdenv
<clever> dansho: gcc is in the nix-shell by default

2019-11-29

<clever> lassulus: he is involved, but isnt the primary culprit this time! lol
<clever> o1lo01ol1o: and it strips the hash off of store paths
<clever> o1lo01ol1o: the unpackPhase function already handles everything for you, and deals with $src being a tar or zip
<clever> o1lo01ol1o: that will also undo +x, potentially breaking scripts
<clever> o1lo01ol1o: when you copy $src, it inherit the read-only perms, you want to use `unpackPhase` to copy it for you, it will land at $sourceRoot
<clever> gyroninja: why do you need --check?
<clever> enteee: oops, ^^
<clever> evanjs: i also think the buildEnv there is pointless
<clever> but i would instead have used -z, which tests that it has been set to anything
<clever> -x tests if the file is executable, and its just "vim" so it looks in the current dir
<clever> it should be -z, not -x
<clever> so you need EDITOR=/run/current-system/sw/bin/vim
<clever> Stuck_: the script wrongly assumes that $EDITOR is an absolute path
<clever> Stuck_: if you `touch vim ; chmod +x vim` does it then work?
<clever> Stuck_: why is it lowercase? is there other lowercase editor's present?
<clever> what does it check for when giving an error?
<clever> Stuck_: is /run/current-system/sw/bin/vimdot a shell script?
<clever> evanjs: there might have been another process downloading the same tarball
<clever> immae: yeah, that can add an extra root, but nixos wont include it as an option in grub
<clever> boogiewoogie: correct, -d just nukes all, and --older-than nukes all older than x, then collects garbage
<clever> boogiewoogie: there is also `nix-collect-garbage --max-freed 10g` to limit how much it deletes, but that only applies after the roots are somehow cleaned up
<clever> boogiewoogie: nix-env -p /nix/var/nix/profiles/system --delete-generations 1 2 3
<clever> rasmusm: in this case, just copy my default.nix to your project, run nix-build, and see what happens
<clever> rasmusm: compilers and libraries should never be installed when using nix
<clever> ,libraries rasmusm
<clever> it asumes that `make` is enough to build your project
<clever> rasmusm: you could try dropping my default.nix into your project, and then just nix-build it with zero changes, and see what happens
<clever> rasmusm: you can use `nix-build --arg nixpkgs '<nixpkgs>'` to bypass the pin on line 1 for testing, and if that rev works, grab the rev from `nix eval nixpkgs.lib.version` and update the pin
<clever> grabbing an example...
<clever> rasmusm: they can also be accessed under pkgsCross
<clever> deni: yeah, it assumes you have a config.yaml file, that describes which cardano nodes to deploy, and how they are inter-connected
<clever> that whole system is being redone now
<clever> so we often have to `io modify` to re-sync the state, then use bare `nixops deploy`
<clever> sadly, `io deploy -o foo` maps to `nixops deploy --include foo`, but lacks support for multiple hosts
<clever> deni: yeah, you use `io deploy` and `io modify` instead
<clever> iohk/common/NixOps.hs: nixops o c "modify" $ Arg <$> cFiles
<clever> deni: yep, and its in that same repo
<clever> that complexity has just been moved into nix/sources.nix, and is now managed by niv
<clever> it used to be more complex, pre-niv, since it had to deal with the json files and fetchTarball
<clever> and thats the contents
<clever> (import ./nix/sources.nix).nixpkgs
<clever> deni: there is a haskell util that will build `fetch-nixpkgs.nix`, and then run `nixops modify` on that path
<clever> deni: since darwin cant build linux
<clever> deni: nixops on single-user darwin, will also automate doing that for you
<clever> deni: if you have /etc/nix/machines setup, it can also take advantage of those, as it builds the local copy
<clever> deni: nix-build itself, will then read whatever foo is, which could be a symlink on your machine
<clever> deni: and every time you try to deploy, it will `nix-build -I nixpkgs=foo <something>`
<clever> deni: it just bakes the `-I nixpkgs=foo` into the sqlite file
<clever> for my personal stuff, ive mostly just been installing nixops system wide, using modify -I, and running it from any dir
<clever> deni: if your using direnv, thats likely the simplest
<clever> deni: oh, one other option, just change $NIX_PATH before you run any nixops commands!
<clever> deni: instead, you `nix-build nix/sources.nix -A nixpkgs -o nixpkgs` to replace the symlink nixops looks at
<clever> deni: one variation to that idea, you can `nixops modify -I nixpkgs=/path/to/some/nixpkgs` and then never modify again
<clever> and `mymachine/configuration.nix` entirely ignores niv
<clever> but the version of nixos used by `mymachine` wont obey niv
<clever> so if you do `hello` anywhere after line 3, it will obey niv
<clever> modify just changes which nix files it reads
<clever> every call to `nixops deploy` and `nixops info` will re-read the nix files
<clever> only when you want to change which deployment files you use, or the -I nixpkgs=
<clever> deni: there is a thing using scopedImport to mutate <nixpkgs> after its too late to change, but it harms performance
<clever> deni: i dont think its possible to properly tell nixops to obey niv right now, you would need a shell script that pulls the path out of niv, and does `nixops modify`
<clever> deni: that line will bake a `-I foo=bar` into the sqlite state, and then `nixops deploy` will always obey that `-I foo=bar` automatically
<clever> deni: definitely
<clever> nice, i still need to try that out
<clever> that explains things
<clever> ah, its not my script doing it
<clever> deni: oh wait, one sec
<clever> deni: that sounds more like the initrd is broken
<clever> if you knew the hostnames nixops is using, ahead of time
<clever> deni: so you could use ~/.ssh/config to enforce proxy-jump's when deploying
<clever> deni: it respects both /etc/hosts and ~/.ssh/config
<clever> deni: or you boot the target into the nixos installer, define that its a nixos installer, and that nixops has to install the os for you
<clever> deni: either, you boot the target into ubuntu, and give nixops a way to ssh into root, and define that it is ubuntu, make it nixos!
<clever> deni: my plans in https://github.com/NixOS/nixops/issues/1189 would also automate that further, for your case, you would have 2 ways to start
<clever> deni: oops, ^^
<clever> daGrevis: yeah, thats basically it
<clever> inf: which era does that fit into? lol
<clever> tgt-admin (a perl script) will read the config file, and then use tgtadm (an ELF binary) to remotely modify tgtd (the ELF daemon), and make the state match the config
<clever> the ELF binary, doesnt even support the tgtd config file, and has no way to persist state
<clever> tgt-admin is a perl script
<clever> tgtadm is a ELF binary
<clever> it has both tgtadm and tgt-admin!
<clever> then you have some packages, like tgtd
<clever> 2019-11-17 03:49:22< clever> wedens[m]: if you `nix-channel --add https://githib.com/nixos/nixpkgs/archive/REV.tar.gz nixos`, and then `nix-channel --update nixos`, it will fetch the given rev
<clever> Miyu-saki: one minute
<clever> jgt: yeah
<clever> jgt: or switch nixops over to kexec!
<clever> jgt: you need to figure out how nixops is copying that file to /usr/bin/nixos-generate-config, and make sure nixops patches in a #!/usr/bin/perl automatically
<clever> these numbers are mildly alarming to me
<clever> 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 6
<clever> 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 4
<clever> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
<clever> jgt: there are some scripts in nixops-hetzner, that should be patching it before shipping it over, those might be broken
<clever> jgt: messy!!
<clever> jgt: https://github.com/NixOS/nixops/issues/1189 is my plan to fully automate that, on all backends
<clever> jgt: the kexec stuff makefu just used above, prevents this kind of issue and more
<clever> if bash is told to run a +x'd file with an invalid #! line, bash just blindly runs itself on the "script"
<clever> jgt: the #! hasnt been patched to perl, so bash is trying to parse the perl code
<clever> c2d ~ # umask(0022);
<clever> -bash: syntax error near unexpected token `0022'
<clever> jgt: look at line 1 on github
<clever> jgt: what do you see on line 11?
<clever> makefu: ah, yeah, i still need to fix that typo

2019-11-28

<clever> in my case, i also had a non-obvious crash when i switched from slim to lightdm, which cost me an hour of time to recover from
<clever> edef: not sure, it also depends on which desktop manager your using, and if its that fragile
<clever> gyroninja: nixos will go out of its way to not restart display-manager, but some things like dbus arent flagged as such, and your desktop manager may crash, which effectively behaves the same as logging out
<clever> alexarice[m]: but callCabal2nix may be better, to obey the new deps
<clever> alexarice[m]: with haskell.lib.overrideCabal, yes
<clever> infinisil: https://github.com/cleverca22/nix-tests/commit/aa7879de6cc6c967e07081c974fab7f9d1de5ed3 no rush, this example is too simple to gain more errors!
<clever> yep, instant repro
<clever> then youll have something much simpler, and it can sit for a while without bitrot
<clever> i'll see if i can make a simple repro
<clever> i dont think you will need the binary cache, the speed of the failure implies it isnt reaching IFD
<clever> the modules are local, nixpkgs is un-touched
<clever> yeah
<clever> infinisil: i can push a branch if you want to look at it closer...
<clever> 7 pgpass = builtins.toFile "pgpass" "${cfg.postgres.socketdir}:${toString cfg.postgres.port}:${cfg.postgres.database}:${cfg.postgres.user}:*";
<clever> 129 services.cardano-exporter = {
<clever> 130 inherit pgpass;
<clever> while evaluating the attribute 'config.services.cardano-exporter.pgpass' at undefined position:
<clever> so the entire block should be a no-op
<clever> but the mkIf isnt set as far as i can see
<clever> the option doesnt exist, because its module wasnt in imports
<clever> The option `services.byron-proxy' defined in `/nix/store/jn9mvgfaj1j3698j0y6mvz3bcksdq45p-source/nix/nixos/cardano-cluster-service.nix' does not exist.
<clever> infinisil: ok, thats weird, config = mkIf false { services.doesnt.exist = anything; }; fails
<clever> srid: i think a better solution, is to always add X to imports, but then use mkIf and config= within there, to make the effects conditional
<clever> infinisil: but builtins.currentSystem can differ, if you are evaling an arm expr on x86, and then farming it out to arm build machines
<clever> if*
<clever> id say those should go under programs.mbsync, of they arent services
<clever> niso: system services are global to the system
<clever> niso: user services run a duplicate copy for each signed in user, and run as that uid
<clever> niso: systemctl --user vs systemctl --system (the default)
<clever> niso: system or user services?
<clever> header files are in the same output as executables!!
<clever> and the more i look at the libnotify package, the more i want to PR it!
<clever> niso: there is no libnotify binary in bin/
<clever> $ ls /nix/store/i2ca8vp2rl4q0wg7izs4c2qcs4pd9sxw-libnotify-0.7.8/bin
<clever> notify-send
<clever> niso: not currently running those, but i vaguely remember notify-send just working, back when i ran gentoo
<clever> strace shows this
<clever> [pid 15446] connect(5, {sa_family=AF_UNIX, sun_path=@"/tmp/dbus-JlB0BuUP4s"}, 23) = -1 ECONNREFUSED (Connection refused)
<clever> running plain xfce
<clever> no popup here either, and i didnt have notify-send in my PATH
<clever> m3lt900: the full url to the archive, from the download a rev as a tar link
<clever> tilpner: nix-prefetch-url --unpack in this case
<clever> Thra11: there is also `nix-store -l /nix/store/foo` for the old api, which only supports logs on the current machine
<clever> Thra11: i think that depends on which protocol your using to treat it as a cache
<clever> Thra11: you can also use the `nix log` command to read logs from the binary cache
<clever> this produces json output for me
<clever> Thra11: the generate-programs-index in the nixos-channel-scripts repo, and also nix-index/nix-locate read it
<clever> Thra11: brotoli i think?
<clever> Shouou: in this case, prepend must be a list of cpio archives, that get prepended to the initrd, and then the whole thing is compressed
<clever> Shouou: the shell script being used as a builder, then does something with $prepend
<clever> Shouou: all attributes you pass to mkDerivation become env vars at build time
<clever> and if you `unset NIX_PATH`, you can find all of them, because they will hard-fail
<clever> jonge[m]: it would be better to just replace all instances of <nixpkgs> with something like `import (import ./fetch-nixpkgs.nix) {}`
<clever> jonge[m]: you would need to use scopedImport, but thats messy and harms performance
<clever> Jarva: is boot.loader.grub.enable = true; set?
<clever> and cat to confirm which one it is
<clever> try using ls to poke around, and find one?
<clever> sounds like it couldnt find a grub.conf
<clever> rescue mode?
<clever> does it have a nixos logo anywhere?
<clever> Jarva: can you take a photo of the grub?
<clever> Jarva: does the grub version say ubuntu?
<clever> Jarva: nix-env -p /nix/var/nix/profiles/system -f '<nixpkgs/nixos>' -I nixos-config=/etc/nixos/configuration.nix --set -A system