2019-11-12

<clever> kenran: possibly inside a set, as { something = pkgs.writeTextFile ...; }
<clever> kenran: it would be a derivation that just goes writeTextFile directly
<clever> kenran: it goes in something.nix
<clever> kenran: you can point -o anywhere you want, if you want it somewhere else
<clever> kenran: nix will generate the file, at a random path under /nix/store/, and the `-o /usr/local/etc/something.ini` will generate a symlink, pointing to that random path
<clever> kenran: something.nix is a file you need to write, that describes the contents, but not the location
<clever> yep
<clever> bahamas: try doing `python3.withPackages` inside `nix repl '<nixpkgs>'`
<clever> atlas_: there is also #nixos-chat for more off-topic stuff
<clever> atlas_: #nix-darwin
<clever> i just blindly `mkdir -pv $out/bin` and then `cp foo $out/bin/foo` and thats it
<clever> gyroninja: line 986 will also add a `--prefix=$out` when running configure
<clever> gyroninja: $out is the main one, all derivations must put files there by default
<clever> there should be dozens of examples in nixpkgs
<clever> then nix will generate the ini file for you, and drop a symlink there
<clever> kenran: you probably want to use pkgs.writeTextFile then, and then `nix-build something.nix -A something -o /usr/local/etc/something.ono`
<clever> kenran: is the ini file in /etc? then a nixos module should be generating it
<clever> rizary_: you could use pkgs.runCommand to generate a zip containing the files you want, and $out/nix-support/hydra-build-products to expose a download link in hydra's UI
<clever> i cant think of any other programs that are more open
<clever> bdju: yeah, anything with free = false; requires allowUnfree = true;
<clever> bdju: that one is free-ish
<clever> > unrar.meta.license
<clever> that would let you override things without changing NIX_PATH
<clever> Raito_Bezarius: you can always use -I nixpkgs=/whatever with `nixops deploy`, and you can use `nixops modify -I nixpkgs=/whatever deployment.nix` to make that override permanent
<clever> Raito_Bezarius: yeah, the first entry forces <nixpkgs> to always be roots nixpkgs, and to ignore what your current user has
<clever> echo $NIX_PATH ?
<clever> youll need to refer to the value of $NIX_PATH
<clever> so if the pathes are identical, then the nixpkgs hasnt changed
<clever> the hashes in the store paths, are all hashes of the build directions
<clever> your welcome
<clever> just nix-channel --update, as root
<clever> Raito_Bezarius: nix-channel --list, as root
<clever> Raito_Bezarius: then it should use whatever channel root is using
<clever> Raito_Bezarius: `nix-instantiate --find-file nixpkgs`
<clever> Raito_Bezarius: then nixops should be using whatever <nixpkgs> maps to in $NIX_PATH
<clever> Raito_Bezarius: is `Nix path` listed at all?
<clever> Raito_Bezarius: what about before the host list, can you pastebin that part?
<clever> Raito_Bezarius: what does `nixops info` report?
<clever> Raito_Bezarius: forcing it to re-copy wont make any difference then
<clever> Raito_Bezarius: store paths are read-only, so there isnt much point in re-copying things

2019-11-11

<clever> adisbladis: but if your on a none backend, youll need to edit the python to make it behave more like aws
<clever> adisbladis: in the case of the aws backend, if you simply edit /root/.ssh/authorized_keys, the keys nixops is managing will cease to be of value
<clever> adisbladis: for other backends, nixops adds it to the nixos config
<clever> adisbladis: for aws, nixops creates an aws keypair, and relies on the scripts in the ami to embed it into /root/.ssh/authorized_keys
<clever> adisbladis: nixops creating its own keys, is backend dependant
<clever> adisbladis: ah, so youve set fileSystems."/" = { fsType = "tmpfs"; }; ?
<clever> adisbladis: why is / a tmpfs then?
<clever> adisbladis: how is it booting? netboot image?
<clever> adisbladis: nixos must be setting an upper limit somewhere
<clever> adisbladis: i dont see any sign of a 3gig limit, what happens if you just mount a new tmpfs to an empty dir?
<clever> 3619 ->>>>>>> * Per default we only allow half of the physical ram per
<clever> 3620 ->>>>>>> * tmpfs instance, limiting inodes to one per page of lowmem;
<clever> 3621 ->>>>>>> * but the internal instance is left unlimited.
<clever> adisbladis: it also has a nr_blocks= mount option, which just bypasses the byte->block conversion
<clever> 104 ->>>>>>>return totalram_pages / 2;
<clever> 102 static unsigned long shmem_default_max_blocks(void)
<clever> adisbladis: you can explicitely set `size=60%` and it will figure things out on its own
<clever> 3369 ->>>>>>>->>>>>>>->>>>>>>size = memparse(value,&rest);
<clever> 3370 ->>>>>>>->>>>>>>->>>>>>>if (*rest == '%') {
<clever> 3367 ->>>>>>>->>>>>>>if (!strcmp(this_char,"size")) {
<clever> adisbladis: pretty sure its this file
<clever> 3431 ->>>>>>>->>>>>>>->>>>>>>pr_err("tmpfs: Bad mount option %s\n", this_char);
<clever> mm/shmem.c
<clever> adisbladis: kernel source is your best option
<clever> adisbladis: there must be an upper limit on tmpfs, that ive never seen, due to lack of insane hardware :P
<clever> adisbladis: 94gig of ram!?
<clever> adisbladis: and `free -g` ?
<clever> adisbladis: is / actually a tmpfs? what is the full output of `mount` ?
<clever> adisbladis: yeah, if a size isnt specified, the kernel defaults the size to 50% of ram
<clever> and nixos-rebuild --rollback wont undo --upgrade fully
<clever> hodapp: nixos and nix-channel have seperate generations, so its not entirely atomic
<clever> hodapp: behind the scenes, all --upgrade does, is run `nix-channel --update` for you
<clever> hodapp: and you only need the --upgrade once, even if it fails, the channels are still updated
<clever> hodapp: it loosk like irony-server is broken, simplest option is to disable/remove that
<clever> hodapp: what was the full output when it failed?
<clever> asymmetric: https://github.com/cleverca22/nixos-configs/blob/master/rtmp.nix is how i enabled rtmp in nginx
<clever> asymmetric: then you want to add it to the configureFlags with an override
<clever> asymmetric: is that a flag for nginx itself, or the nginx configure script?
<clever> Baughn: add one more element to NIX_PATH and it should work
<clever> Baughn: its on the nix issue tracker, and i think it was under `nix run`, both run and search are broken
<clever> Baughn: by default, you have 1 channel and 4 elements in NIX_PATH, so it works
<clever> Baughn: it happens if you have more channels then :'s in $NIX_PATH
<clever> Baughn: thats a known bug (and fixed in master)
<clever> Bryophyllum: which line does it point to?
<clever> warbo: you are asking it, why does a depend on b
<clever> warbo: i tend to |less, then /search and follow the lines up
<clever> warbo: try `nix-store --query --tree /nix/store/foo.drv`
<clever> pie_: thats what happens if you `nix-shell -p ']; foo = ['`
<clever> pie_: that one doesnt, was showing why the old cmd fails
<clever> pie_: looks like it deleted sdlmame and replaced it with original mame?
<clever> and all branches of this repo, mirror the channels
<clever> durka: github says which branch the commit is in
<clever> every user has their own set of channels, and roots are also able to be used by other users
<clever> durka: nix-channel --list, as both your user and root
<clever> ,unstable durka
<clever> durka: which channel are you on?
<clever> durka: checking nixpkgs-channels confirms, its only in nixos-unstable
<clever> durka: thats weird, github says its part of master, but its old enough to be in a channel, yet isnt showing that
<clever> nornagon: maybe i have a bit too much swap?
<clever> Swap: 62 15 46
<clever> Mem: 31 25 5 0 1 5
<clever> total used free shared buff/cache available
<clever> $ free -g
<clever> nornagon: thats why i always have at least some swap
<clever> nornagon: how many nix-daemon's running? anything interesting at the end of dmesg?
<clever> nornagon: free -m ?
<clever> nornagon: journalctl -f -u nix-daemon.service
<clever> wlckd: this is an example from what ive been using
<clever> 173 };
<clever> 168 fonts = {
<clever> 169 enableFontDir = true;
<clever> 172 fonts = [ pkgs.unifont pkgs.noto-fonts-cjk ];
<clever> 171 fontconfig.ultimate.substitutions = "ms";
<clever> 170 enableCoreFonts = true;
<clever> wlckd: fonts must in in the fonts.fonts = [ ... ]; list in configuration.nix
<clever> nornagon: that happens sometimes if nix-daemon isnt running, but it should auto-start, try again
<clever> romildo: nixos should merge both, but your cfg may wind up later in the list, mkBefore and mkAfter can enforce the ordering
<clever> but i would just `rm thing2`, rather then force things
<clever> (the symlink would point to nothing)
<clever> Klein37: in my case, the only root is a result symlink from `nix-build -o thing2`, so the damage would have been much less
<clever> /home/clever/apps/nixpkgs-master/thing2 -> /nix/store/cbhfivwr2jcyk9cp3gmx3wy7gpqvgywk-vscode-extension-ms-vsliveshare-vsliveshare-1.0.488
<clever> $ nix-store -q --roots /nix/store/cbhfivwr2jcyk9cp3gmx3wy7gpqvgywk-vscode-extension-ms-vsliveshare-vsliveshare-1.0.488
<clever> Klein37: and then a mix of removing it from things, nix-env --delete-generations, and nix why-depends, to remove the roots
<clever> Klein37: next time, use `nix-store --query --roots /nix/store/foo` to see why something cant be deleted
<clever> Klein37: your only solution is to boot the nixos install iso, and re-run nixos-install, which will remake the missing parts, from configuration.nix
<clever> Klein37: never use --ignore-liveness, you probably just deleted the entire nixos build, and nix itself
<clever> EsperLily: yeah, not much can cache that right now
<clever> EsperLily: https://github.com/NixOS/nix/pull/3205 may also be of use in the future
<clever> EsperLily: if your developing somethng, just build it in nix-shell, and the .o files will persist between runs of `make`
<clever> EsperLily: extra-sandbox-paths are read-only i believe
<clever> EsperLily: but the sandbox doesnt allow you to access a shared cache dir
<clever> elvishjerricco: unbind each one, and see what breaks, then re-bind if its not that
<clever> red[m]: ah, tmux may undo a lot of those vars

2019-11-10

<clever> red[m]: $NIX_LDFLAGS and $NIX_CFLAGS_COMPILE
<clever> red[m]: its tied into cc-wrapper, and only impacts gcc, so ponyc may ignore it
<clever> red[m]: so you just use the normal -ltermbox you always use
<clever> red[m]: nix automatically adds a -L flag for you
<clever> then you just try each one
<clever> elvishjerricco: causing whatever usb devices are behind it, to vanish
<clever> elvishjerricco: but the above steps let you basically disconnect any pci device from its driver
<clever> elvishjerricco: i dont know of a way to directly do that
<clever> just note, if you disconnect the usb card from the usb driver, you loose your keyboard, so test over ssh!
<clever> elvishjerricco: you can use the bind find to re-connect things
<clever> elvishjerricco: and i think if you `echo 00:16.2` to this file, it will just detatch the driver from the card, causing it was doing to stop (and all usb devices to unplug)
<clever> --w------- 1 root root 4096 Nov 10 19:47 /sys/bus/pci/drivers/ehci-pci/unbind
<clever> elvishjerricco: with this, i can figure out which driver is using a given card
<clever> Kernel driver in use: ehci-pci
<clever> 00:16.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller (prog-if 20 [EHCI])
<clever> instead of imports = [ {services.foo = ...;} {services.foo = ...; } ];
<clever> so you can do services.foo = mkMerge [ .... ];
<clever> mkMerge basically does the same thing as imports, but works at any node
<clever> while with mkMerge, it will verbosely complain if you set something twice
<clever> also, with recurisveUpdate and //, it will just silently overwrite things
<clever> [1] and [2] turns into [2], not [1 2]
<clever> selfsymmetric-mu: but that wont respect nixos config merge rules
<clever> it takes a list of nixos configs
<clever> otwieracz: if its nixos config, you can also use mkMerge
<clever> otwieracz: the way i personally do it, is i just define a users.users.foo, give it a home dir, and tell nixos to createHome = true;
<clever> otwieracz: the "new" way is to use systemd tempfiles, but that name feels backwards and ive not looked into how to do it yet
<clever> otwieracz: you can then freely use mkdir and chown to prepare things
<clever> otwieracz: if you set PermissionsStartOnly, then the User= only affects ExecStart, so ExecPreStart gets ran as root
<clever> Thra11_: set nixpkgs.overlays in the nixos config
<clever> and if thats a tmpfs, it will be limited to 50% of ram, so the journal is limited to 5% of ram
<clever> CMCDragonkai: it will not use more then 4gig for the logs, and not use more then 10% of the space on whatever fs is mounted to /var/log/journal
<clever> CMCDragonkai: it will limit itself to keep a certain amount free, not use more then a certain amount (both absolute, and percentage), and gc automatically based on those params
<clever> CMCDragonkai: `man journald.conf`
<clever> boogiewoogie: and 2 hours ago, the status was changed to "has port to stable", so maybe we just have to wait for stable to update?
<clever> boogiewoogie: https://github.com/NixOS/nixpkgs/pull/72804 looks like its been fixed on unstable
<clever> Thra11_: some do
<clever> Thra11_: facetimehd is only needed if you want to use the facetime (webcam) on a macbook, i think
<clever> boogiewoogie: theres already a pr somewhere to fix it
<clever> boogiewoogie: its some firmware for apple hardware
<clever> EsperLily: bash can do the same thing, on its own
<clever> $ type -P ls
<clever> /run/current-system/sw/bin/ls
<clever> EsperLily: some people alias which to a special cmd, that pipes all aliases and shell builtins to which
<clever> ,locate bin which
<clever> each overlay gets a different super, which builds up as nix goes thru the overlay list
<clever> Thra11_: self is the result of every overlay being applied
<clever> Thra11_: super is the result of all previous overlays being applied
<clever> Thra11_: if you use super.lib, then you will ignore what future overlays did to lib
<clever> Thra11_: i would prefer self.lib in most cases though
<clever> Thra11_: that only matters if other overlays are changing lib
<clever> ,profiling
<clever> __monty__: not really
<clever> pinkien: what partition did you mount to /mnt/boot/ ?
<clever> pinkien: what partition did you mount to /mnt/boot/ ?
<clever> pinkien: what partition did you mount to /mnt/boot/ ?
<clever> jakubracek: nixos should create that file on the first bootup
<clever> jakubracek: if you `ls /mnt/` what files do you see?
<clever> (function application)
<clever> thats what allows `nix-shell -p 'foo bar'` to work right, even in a nix list
<clever> with import <nixpkgs> {}; pkgs.runCommandCC "shell" { buildInputs = [ (]; foo = [) ]; } ""
<clever> with the modern code, that turns into:
<clever> edef: yep
<clever> nh2: ^
<clever> (if built by nixos)
<clever> and it still obeys the nixos option
<clever> and now i can cycle between nix-build and nixos, with zero changes
<clever> then i can nix-build it, or `pkgs.callPackage ./vim.nix { fat = config.programs.vim.fat; }`
<clever> { pkgs ? import <nixpkgs> {}, fat ? false }:
<clever> i could also make it start with:
<clever> with a minor change (make it not a module, add with import <nixpkgs>{};), i can nix-build it, and ./result/bin/vim to test the changes (or use it on somebody elses machine)
<clever> wedens[m]: this generates a vim, that has a vimrc baked into it, along with plugins
<clever> wedens[m]: and it will show the changes since the last commit (last commit at the time it was built)
<clever> wedens[m]: in my case, its even saving the `.git` dir, so i can just `cd /run/current-system/nixcfg ; git diff`
<clever> its also visible in every generation
<clever> lrwxrwxrwx 1 root root 50 Dec 31 1969 /nix/var/nix/profiles/system-480-link/nixcfg -> /nix/store/d5xr9cp0yyh5kl0xa7ck4npcr5yj63dm-nixcfg
<clever> wedens[m]: this will put a copy of whatever is in . at /run/current-system/nixcfg/
<clever> wedens[m]: i have a trick for that
<clever> wedens[m]: hydra builds all of the iso's for every channel revision, but only a select few are mirrored to http for easy access
<clever> you can also open https://releases.nixos.org/nixos/unstable/nixos-20.03pre200231.7827d3f4497 in the browser, to get info about that version
<clever> wedens[m]: getting URL's like that is a bit more complex, but will then keep the version info that helps with this problem in the future
<clever> which has the .version-suffix file, so nixos can label itself right
<clever> and that will give you the tar that nix-channel would have used
<clever> then use NIX_PATH=nixpkgs=https://releases.nixos.org/nixos/unstable/nixos-20.03pre200231.7827d3f4497/nixexprs.tar.xz i think it was
<clever> wedens[m]: if you query a channel like this, youll get redirected to a url with a rev in it
<clever> [clever@amd-nixos:~]$ curl https://nixos.org/channels/nixos-unstable -i
<clever> yeah
<clever> wedens[m]: you can also point NIX_PATH to a tarball that was made for a channel, but those are a bit more tricky to find
<clever> wedens[m]: thats much simpler if it was built from a channel
<clever> then go forwards/backwards in history
<clever> but if you guess, and use nix-diff and nix-instantiate, you can see how much differs between whats built and your guess
<clever> no easy way to find the nixpkgs rev directly
<clever> ah, those also lack .version-suffix
<clever> a url or a dir?
<clever> wedens[m]: but what was it pointing to?
<clever> wedens[m]: then it was built from a git clone, and the .version-suffix file is missing
<clever> gyroninja: only other thing i can think of, is things like sse2 features
<clever> thats weird
<clever> gyroninja: likely, none of the inputs have changed, so hydra hasnt bothered to try again, since doing the exact same thing twice is the definition of insanity
<clever> gyroninja: its likely just a random failure, and the hydra job needs to be restarted
<clever> gyroninja: and the .drv nixpkgs generates, is identical to the one hydra has
<clever> gyroninja: unxz is already in the PATH of that derivation
<clever> gyroninja: what was the link to the hydra failure?
<clever> or your copy is older, and its not xz yet
<clever> its possible that your copy is newer and has a fix
<clever> are you building with the same nixpkgs hydra used?
<clever> oh, on yours it works
<clever> because the src attribute is still pointing to an xz'd file
<clever> gyroninja: the src ends in .xz, so it needs xz to unpack
<clever> wedens[m]: bc94dcf5002 is the rev i build 480 from
<clever> lrwxrwxrwx 1 root root 93 Jun 1 18:38 /nix/var/nix/profiles/system-480-link -> /nix/store/hsr6hw4scz98i08rp2igd0724ds1xnil-nixos-system-amd-nixos-19.09pre179307.bc94dcf5002
<clever> [root@amd-nixos:~]# ls -l /nix/var/nix/profiles/system-480-link
<clever> wedens[m]: its in the name of the build
<clever> gyroninja: you probably have to add xz to the nativeBuildInputs
<clever> wikiemol: it prints the log from building it
<clever> wikiemol: run `nix-store -l /nix/store/foo.drv`
<clever> atlas_: but it may not work once catalina is finalized
<clever> atlas_: there is a post somewhere on github, on how to do it
<clever> maralorn: which will work with your symlinks
<clever> maralorn: you can also use `nix run -f '<unstable>' firefox` i think
<clever> maralorn: probably
<clever> maralorn: the new nix command follows slightly different and weird rules
<clever> maralorn: ah, that might be why, it needs a nixpkgs=/path/to/nixpkgs entry
<clever> maralorn: what is the contents of $NIX_PATH ?

2019-11-09

<clever> maralorn: you can also give it store paths, nix why-depends ./result /nix/store/fat-thing
<clever> lane-s: thats the iso with 5.3, and using kernelPackages = pkgs.linuxPackages_latest; will keep you on 5.3
<clever> 2019-11-07 01:13:05< clever> rotaerk: https://hydra.nixos.org/build/105246685
<clever> 2019-11-07 01:13:37< clever> rotaerk: that is the linux 5.3 iso image, for the current build of nixos-unstable
<clever> lane-s: you can get an iso image, that is using 5.3 on bootup, and then use that to fix things
<clever> thats not much different from using patchelf
<clever> it relies on the ld.so from the target being compatible
<clever> Xal: that uses musl-c, a static libc
<clever> > pkgsCross.muslpi.hello
<clever> Xal: ^
<clever> > pkgsCross.raspberryPi.hello
<clever> if your on nixos, the curl script to install nix wont work
<clever> atlas_: thats just how nix works
<clever> atlas_: all binaries have /nix/store hard-coded into them
<clever> atlas_: there are directions somewhere on how to make / writable again
<clever> atlas_: you would need to re-compile every single package from scratch
<clever> lane-s: you want something like boot.kernelPackages = unstable.linuxPackages_latest;
<clever> ,unstable lane-s
<clever> lane-s: boot.kernelPackages = pkgs.linuxPackages_latest; will get you 5.3, if your on unstable
<clever> lane-s: you need the 5.3 kernel for iwlwifi to support it
<clever> lane-s: ah, thats the exact same pid as the last guy with this issue
<clever> lane-s: what does `lspci -nn` say?
<clever> dmesg would show when firmware is missing
<clever> firmware may not be
<clever> lane-s: the source is open, so the module is always present
<clever> lane-s: my laptop is using iwlwifi, and has had fairly flaky wifi since nixcon (when i did an upgrade)
<clever> lane-s: a: by using @clever, i dont notice it, b: it sounds like your wifi drivers may be having similar problems that i'm having
<clever> had*
<clever> babariviere[m]: previously, the resolv.conf has 192.168.1.1
<clever> lane-s: how stable are pings to other services?
<clever> omnipotententity: so you dont have to search for sqlite, just blindly -lsqlite3
<clever> omnipotententity: nix itself, would have already put sqlite into the linkers search path
<clever> omnipotententity: what do the docs say find_path and find_library are doing, to actually find things?
<clever> omnipotententity: what does that do inside its find_package function?
<clever> omnipotententity: and where if find_package defined?