2018-04-07

<clever> Lisanna: i just use raw makefiles in all of my nix based projects
<clever> infinisil: the shell doesnt even stream the stdout on, it just shares the file handle with the child
<clever> tos9: was /boot mounted when you ran nixos-rebuild boot?
<clever> tos9: try to unset that too
<clever> tos9: also check `env | grep user/0` to see if anything else points there
<clever> tos9: just unset, thats a command
<clever> tos9: unset TMPDIR
<clever> tos9: oh, i think it got renamed into its own tool, nixos-enter
<clever> or just opening and closing the lid until it comes on :P
<clever> and i found that changing the brightness, with the display at the right angle, would fix it
<clever> with one of my laptops, i suspect there was a partial break in the ribbon cable that controlled the backlight
<clever> but i saw more uses in it, and left it enabled
<clever> so it only had to work once
<clever> it was originally meant to shuffle /nix into its own dataset on my laptop
<clever> so if something in nixpkgs breaks nixos horidly, it also breaks the rescue env
<clever> only major problem, it rebuilds with the same nixpkgs as the host
<clever> yep
<clever> potentially breaking in the same way as the machine you want to fix
<clever> but it will cost more /boot space, and make it more fragile
<clever> and you can customize that however you want, you could even go nuts and put xorg into it with xfce
<clever> yeah
<clever> and as long as your using grub, and have ~300mb on /boot, it will work
<clever> tos9: in your imports list, just do ./rescue_boot.nix
<clever> tos9: yeah
<clever> elvishjerricco: i think dtz is working on something like that
<clever> you can just dd the iso into any normal usb stick
<clever> tos9: yeah, also, the iso works on USB
<clever> tos9: just run passwd on the host, read the hash from /etc/shadow, then edit /mnt/etc/shadow
<clever> tos9: ah, id try the iso again, also, there is a shortcut to get around chroot
<clever> ruhatch: --include
<clever> tos9: you will need to use a ps2 keyboard if possible, or try the iso again
<clever> tos9: ah, that can happen if you dont have usb drivers in the initrd
<clever> tos9: so you can get a fully working nixos, with more basic (but still customizable config) as a rescue env
<clever> tos9: https://github.com/cleverca22/nixos-configs/blob/master/rescue_boot.nix also, if you insert this into your configuration.nix via the imports line, it will put an entire install image in /boot, and your grub menu
<clever> it will complain it doesnt exist, tell it to continue anyways
<clever> tos9: another quick fix is to just edit the kernel params in grub, change init= to init=/bin/sh
<clever> so its trying to do a full install
<clever> tos9: i suspect your iso is on the version that has broken --chroot support
<clever> oops
<clever> switch wont work in a chroot
<clever> tnks: and also, you need to use nixos-rebuild boot
<clever> tnks: nixos-install --chroot

2018-04-06

<clever> tnks: it will build the arm version of cmake, then try to run it on an x86 machine, and obviously fail
<clever> tnks: yeah, most packages just use buildInputs, it only becomes a problem if somebody ever wants to cross-compile it
<clever> infinisil: ah
<clever> tnks: if your not cross-compiling, they both do the same thing
<clever> tnks: buildInputs are runtime things like libraries,that have to be cross-compiled to the target platform
<clever> tnks: nativeBuildInputs are compile-time only things like cmake, that need to run on the machine building the package
<clever> infinisil: "" ?
<clever> tnks: nix detects the runtime ones by scanning $out to see what you are still refering to
<clever> tnks: neither winds up being a runtime dependency
<clever> elvishjerricco: i have a debian and ubuntu iso that i just booted inside virtualbox and installed normally
<clever> id just use nix-serve.script if i could
<clever> oh wait, yeah, the nix-remote hmmm
<clever> infinisil: ExecStart can just be line 8 alone
<clever> infinisil: you dont need writeScript for that also
<clever> example?
<clever> infinisil: so you cant use mkForce within the serviceConfig
<clever> infinisil: the option is serviceConfig, not ExecStart
<clever> lejonet: ExecStart cant really be overriden easily
<clever> zsh could also add that spare \n
<clever> foldingcookie: bash on nixos always has a \n at the start of the prompt, leaving a spare blank line 90% of the time
<clever> foldingcookie: for bash on ubuntu, the prompt is prefixed by the unterminated line, which is fugly but still intact
<clever> judson: there is a configuration-common.nix nearby, that has overrides for it
<clever> foldingcookie: probably from the /etc/zshrc nixos made
<clever> lejonet: then the setuid wrapper calls back to the real binary
<clever> lejonet: chrome had similar problems, the derivation has to be patched to put a symlink into /run/wrappers in the store
<clever> lejonet: yeah
<clever> then you can enable only one unfree package
<clever> lejonet: instead of just blinding allowing all unfree, you give it a function from package name to boolean
<clever> there is also an unfree predicate, let me fidn it
<clever> so home-manager wont work
<clever> lejonet: only root can create the wrappers
<clever> yep
<clever> manually run ssh-keygen on each machine, and then put the publics into the nixops config
<clever> and that
<clever> yeah, its meant to be used by a vpn link, nixops will tunnel the packets over ssh
<clever> lejonet: ah, so that made an lxd binary!
<clever> and it does have capability support
<clever> lejonet: security.wrappers is how the wrappers get made
<clever> preferably in a pastebin
<clever> ruhatch: yeah
<clever> the option i named puts it there
<clever> you can also remove it from systemPackages
<clever> foldingcookie: yes, without that, you wont have a /etc/zshrc and stuff
<clever> ruhatch: what do you see when you ls /etc/systemd/system/ on the machine nixops was controlling?
<clever> foldingcookie: did you programs.zsh.enable = true; ?
<clever> ottidmes: nixos will autodetect that
<clever> ruhatch: nope
<clever> ruhatch: it might be /root/.ssh/id_charon_vpn
<clever> you should find the path to the private in there
<clever> ruhatch: check the .service file for the vpn in /etc/systemd/system/
<clever> ruhatch: you still need your own keys to get a shell, the vpn key is only for the vpn itself
<clever> ruhatch: what happens if you run ssh against that ip?
<clever> ruhatch: you should be able to connect to the ip of the other machine
<clever> [Leary]: it depends on what the type was set to when the option was defined
<clever> there should be an ip on both ends, which you can just use
<clever> ruhatch: if you run `ip addr`, do you see an extra interface?
<clever> ruhatch: i think it generated a systemd service that setup an ssh link between the 2 machines
<clever> ruhatch: nixops configured that
<clever> [Leary]: for most, it will inteligently merge things, for some, it will give a clear failure when they conflict, and for a rare few, it will just pick one over another
<clever> [Leary]: depends on the types of each attribute and the merge functions for those types
<clever> ottidmes: and nixops deploy will revert all changes nixos-rebuild had done
<clever> ottidmes: if you run nixos-rebuild, then it will revert all changes nixops was doing
<clever> Acou_Bass: that would explain why none of my nixos machines have a ~/.pulse/
<clever> Acou_Bass: what about the last-mod timestamp on the symlink?, it may be from ages ago and /tmp has been cleaned up
<clever> Acou_Bass: what exactly does it point to?
<clever> that part msg is perfect, lol
<clever> ShalokShalom2: generally, development time things shouldnt be installed globally when using nix
<clever> Kim_: you can use pkgsi686Linux to access the 32bit versions of packages when doing patchelf
<clever> Kim_: what needs both 32 and 64?
<clever> why are you trying to globally install something with npm?
<clever> you just need to get into the right mindset, then it all makes sense
<clever> they defeat the whole point of nix
<clever> and nix is very against global things like that
<clever> ShalokShalom2: a normal user wont have write access to that path
<clever> ottidmes: and that will only work if the bin of that is already in $PATH
<clever> ShalokShalom2: yeah
<clever> ShalokShalom2: where else would you have it install to?
<clever> ottidmes: i dont think npm global installs can ever work, because they assume the dir npm was installed to is mutable
<clever> benny: yeah, just assign it to another attribute, and that will become an env var at build-time
<clever> benny: run patchShebangs on that directory
<clever> benny: buildInputs only ever land in $PATH
<clever> detran: you could potentially bisect nixpkgs now, but it might take an hour to narrow down the cause
<clever> detran: you should be able to just change the nix-channel after booting the iso, then install
<clever> detran: i'm guessing the kernel doesnt like your hardware, try an older iso
<clever> detran: that should work
<clever> detran: and rdisk2 is the full drive?
<clever> detran: how are you dd'ing the iso to the usb?, what is the exact command?
<clever> judson: librarySystemDepends
<clever> judson: its not a haskell dependency
<clever> nix 2 auto-detects it, so it is now unset
<clever> disasm: originally, nixos was setting that system wide, because nix 1.11 cant auto-detect it
<clever> disasm: that could handle it
<clever> nix-repl has better tab completion, no history, and it uses nix 1.11
<clever> nix repl has somewhat worse tab completion, the repl history persists between restarts, and it uses nix2
<clever> apostolis: there is also `nix repl` without the -, but its ui is slightly different
<clever> apostolis: its an issue caused by nix2
<clever> apostolis: export NIX_REMOTE=daemon
<clever> apostolis: what error?
<clever> judson: gnome3.gtk
<clever> MichaelP: cli
<clever> yeah, if the warning keeps happening, thats generally due to installing nix 2 with nix-env, while running nix 1 as the daemon
<clever> zybell_: so nix has to run with the old config, to make the new config
<clever> zybell_: nope, the issue is that the config is built with nix
<clever> just a bit slow
<clever> that sounds entirely normal
<clever> which will happen any time your doing the upgrade
<clever> zybell_: that warning happens if you run nix2 with a nix1.11 /etc/nix/nix.conf file
<clever> ?
<clever> it should warn you if it took over a minute
<clever> it should be
<clever> stumble: thats nix checking the binary caches
<clever> stumble: name?
<clever> strange
<clever> stumble: if you check top while its hung, is there any high cpu usage?
<clever> stumble: does it hang again if you try the same command again?
<clever> the difference, is that double-single will strip common indents
<clever> mightybyte: double as in ''foo bar''
<clever> mightybyte: yes
<clever> stumble: gist.github.com

2018-04-05

<clever> xxxnasheedxxx: it needs both minetest and minetest_game
<clever> xxxnasheedxxx: oh, minetest is doing weird things with its src
<clever> xxxnasheedxxx: put it in place of fetchurl
<clever> xxxnasheedxxx: nix-build -E 'with import <nixpkgs> {}; minetest.overrideAttrs (drv: { src = fetchurl { url = "https://example.com/foo.tar.gz"; sha256 = "hash"; }; })'
<clever> xxxnasheedxxx: you want to use overrideAttrs to change the src
<clever> { column = 3; file = "/nix/store/vylxsj58k3w71jn3j11xd45s9b71qbkw-nixos-18.03pre130932.cc4677c36ee/nixos/pkgs/top-level/all-packages.nix"; line = 5814; }
<clever> nix-repl> builtins.unsafeGetAttrPos "clangStdenv" pkgs
<clever> [clever@amd-nixos:~]$ nix repl '<nixpkgs>'
<clever> abcrawf: there is a clangStdenv.mkDerivation that may help somethings
<clever> ottidmes: nixos will also save those levels at clean shutdown, and restore them on bootup, so its only ever an isue for fresh boots and maybe newly hot-plugged devices
<clever> ottidmes: alsamixer, f6
<clever> nioncode: virtualbox is a bit more complex to pin, because it involves kernel components
<clever> nixos-rebuild build -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/your_nixpkgs_revision_here.tar.gz
<clever> the 831ef4756e3 at the end is the rev that 358 came from
<clever> lrwxrwxrwx 1 root root 94 Mar 11 12:34 /nix/var/nix/profiles/system-358-link -> /nix/store/xgdzh7klnl9y75qb78jc57x998nb6rj6-nixos-system-amd-nixos--18.03pre129076.831ef4756e3
<clever> nioncode: then your nixpkgs didnt match up, look in the path for the 117 build, and youll find the git rev of nixpkgs
<clever> this path is where i find a copy of it for generation 358
<clever> lrwxrwxrwx 1 root root 50 Dec 31 1969 /nix/var/nix/profiles/system-358-link/nixcfg -> /nix/store/bdwxbw5p2d55zpzilwchigf3gb1x0zbl-nixcfg
<clever> with these 3 lines, all of my nixos config is kept in the nix store
<clever> nioncode: the only way to modify 117 is to know the exact configuration.nix that originally made 117
<clever> the default is in $NIX_PATH
<clever> yorick_: <nixos-config> has to be in NIX_PATH to use nixos-rebuild, so you want to use -I to prepend to the search path
<clever> yorick_: it will fail to find configuration.nix when you do that
<clever> ah right, you can just manually aim at the right generation with test
<clever> or test
<clever> and `nix-store -r /nix/store/kmwd1hq55akdb9sc7l3finr175dajlby-hello-2.10` will just download it from a binary cache

2018-04-04

<clever> fresheyeball: mkdir home ; export HOME=$(realpath home)
<clever> fresheyeball: yep
<clever> fresheyeball: its stuck in the homeless shelter, because it lacks a home
<clever> fresheyeball: that happens if the build tries to touch $HOME
<clever> guillaum1: the entire directory that contains core.nix gets copied into the store, and lands at /run/current-system/nixcfg/
<clever> guillaum1: and this is how you would create backups of the config: https://github.com/cleverca22/nixos-configs/blob/master/core.nix#L117-L119
<clever> guillaum1: and if i then run diffoscope on it, i can see that i had refactored the import statements in the haskell code to silence all compiler warnings, but forgot to nixos-rebuild switch
<clever> guillaum1: in this example, my configuration.nix is intact, but there is a single difference within a util i use in builtkite
<clever> guillaum1: that will tell you how the 2 differ, and then you can manually edit configuration.nix to bring the differences down to zero
<clever> guillaum1: one trick you can use, is to do `nixos-rebuild dry-run` and then use nix-diff to compare it against the .drv from the original system
<clever> guillaum1: not by default, you need some special config to do that
<clever> mpcsh: the problem could be the reverse of what your thinking, some other font is currently missing, and its using FreeMono as a fallback
<clever> sphalerite: if a directory with files exists in /etc, but environment.etc says it should be a symlink to a directory in the store, it currently fails to update the entire entry
<clever> sphalerite: RENAME_EXCHANGE sounds like something setup-etc.pl could use
<clever> but if you set builder, that is disabled
<clever> fresheyeball: the default builder copies the src to . for you
<clever> fresheyeball: can you gist the nix expression you currently have?
<clever> fresheyeball: if you are using builder.sh, all of the helper scripts that copy the src are non-functional
<clever> lejonet: you may also want to look at the nixpkgs expressions for ubootBananaPi to see what makes it special, and how it may need to be modified to suit your board
<clever> lejonet: you also need all the files that qemu-user.nix refers to within the overlays dir
<clever> lejonet: try cloning all of nixos-configs, and add the absolute path of qemu.nix to imports
<clever> dhess: it took several hours just to run the perl configure script, so, really slow :P
<clever> lejonet: the overlay is fully automatic in the module i made, as long as all of the files are in the right place
<clever> lejonet: and it will also upgrade you to 2.0 if you didnt already have it
<clever> lejonet: this module also patches nix 2.0 for you, and configures it
<clever> lejonet: yep
<clever> lejonet: then nix-daemon will believe you can run the native arm gcc, and just work
<clever> lejonet: add this file to your imports in configuration.nix, and then set qemu-user.arm = true; and it will magically configure everything
<clever> lejonet: qemu-user can also be used, one min
<clever> lejonet: an armv7l build slave in /etc/nix/machines, or run it directly on a v7
<clever> so i never got past u-boot
<clever> lejonet: in my case, the power supply was too weak, and the cpu was resetting too much to get a stable boot
<clever> lejonet: there is an SPL in nixpkgs that has worked for me before, let me find it
<clever> lejonet: allwinner chip?
<clever> fusion809: just run nix-build on this file: https://gist.github.com/e2c139c30677506108c1a5bc9ec31089
<clever> thats what i'm writing up now
<clever> fusion809: is that all that is required?
<clever> boot.extraModulePackages = [ config.boot.kernelPackages.broadcom_sta ];
<clever> fusion809: let me type up an example
<clever> first one, you can just generate a new iso with more drivers, using nix
<clever> several ways around that
<clever> ah
<clever> fusion809: why are you trying to install from a chroot on linux?, cant boot the install media?
<clever> fusion809: nix 2.0 uses mount namespaces, and i suspect that those dont work right under a chroot
<clever> that config argument entirely replaces the config.nix file
<clever> import <nixpkgs> { config = { allowUnfree = true; }; }
<clever> yeah, when you import nixpkgs
<clever> robstr: ah, yeah, config.nix needs to contain { allowUnfree = true; }, as the error says
<clever> robstr: thats auto-detected via the meta.license you set
<clever> fusion809: you need to copy /etc/resolv.conf into the chroot for dns to work inside the chroot
<clever> fusion809: is your internet working?
<clever> yeah, exim's module contains `inherit (pkgs) coreutils exim;`, so you need an overlay to modify pkgs.exim
<clever> yeah
<clever> srid: that cant really work, because it would un-patch itself and break
<clever> though the buildEnv already gives you a warning when duplicates exist
<clever> yeah, that could work
<clever> elvishjerricco: behind the scenes, the nix module for nixos does the same thing, it inserts nix.package into the list
<clever> elvishjerricco: yeah, that probably should give a warning, but i'm not sure how id implement that
<clever> anything else will just cause issues
<clever> patrl: the only valid way to update nix on nixos is to set nix.package in configuration.nix
<clever> and then just passwd your way to owning the machine
<clever> Aleksejs: you can always use init=/nix/var/nix/profiles/system/sw/bin/sh in grub to force it into single-user mode
<clever> Aleksejs: it works by just upgrading a single-user nix install into a full nixos install, and renaming everything the old distro left in /
<clever> Aleksejs: i believe jeaye made it based on what i had done when messing around with an old netbook
<clever> infinisil: lol
<clever> infinisil: nice
<clever> yeah, its only an issue if you shadow a binary with a path earlier in your pre-existing $PATH
<clever> it will also clear it any time PATH is modifies, so i just `export PATH=$PATH`
<clever> which shows that it didnt look, it remembered
<clever> on gentoo, it can return this
<clever> bash is hashed (/bin/bash)
<clever> clever@c2d ~ $ type bash
<clever> Lisanna: also, there is "type ls"
<clever> Lisanna: nixos disables that bash feature automatically

2018-04-03

<clever> i keep seeing things like 1200 b/sec sorted above 50 kb/sec!
<clever> the units in iotop are really throwing me off
<clever> are the heavy loads actually a child of nixos-rebuild?
<clever> joepie91: what about the process tree?
<clever> joepie91: nixos-rebuild and any build started by root will generally bypass nix-daemon, so you can just ionice the command directly
<clever> Dezgeg: its clearly never been io-bound on my end
<clever> but it drops really slowly, it doesnt even use 2% of my disk bandwidth capacity
<clever> sphalerite: you can `watch cat /proc/swaps` to see the used swap slowly drop
<clever> ive profiled it before and the issue is somewhere in the memory management area
<clever> obadz: it happens even with plaintext swap
<clever> but to load-balance between them you have to have the same priority, and then the writes are scattered, so perf is murdered on spinning-rust
<clever> so you can double the swapoff speed if you just use 2 swap partitions on the same device
<clever> it uses an abnormally large amount of cpu, and it cant multi-thread
<clever> sphalerite: ive noticed that as well, its a major pain at times
<clever> Turion: after the rebuild finishes, your nix config will be updated
<clever> Turion: because your using nix 1.11 config with nix 2.0
<clever> Turion: its in more of a beta phase right now
<clever> tilpner: the sshd work-around is gone, and it your install was from 2015, the ssh hostkeys will just change on their own and set off mitm alerts
<clever> tilpner: well, this explains something Turion asked: https://github.com/NixOS/nixpkgs/commit/ec80c928255b3886aa2268398ccbbe4279004cff
<clever> sphalerite: the time binary (not the bash builtin) can show that with -v
<clever> Turion: channels/nixos-18.03
<clever> tilpner: sshd should also be in the mix
<clever> thats about the only list i know of
<clever> Turion: grep nixpkgs for stateVersion
<clever> but other services have similar issues that need to be worked around
<clever> so if your not using postgress, then that specific problem wont happen for you when changing the stateVersion
<clever> Turion: postgress is not used by nix at all
<clever> Turion: the 2nd one, is that the admin role that has all control got renamed, so if you know how to use it, you can just create a new one
<clever> Turion: the first incompatible change postgresql had, i think was the on-disk format of the db, you have to export, upgrade, wipe, and import
<clever> yeah, if you deprecate a certain value of it, you would need to make something to migrate the state, and then you have the same issue