2019-09-10

<clever> asymmetric: and it doesnt sort that dir listing
<clever> asymmetric: the display manager will list the contents of the dir, that has the enabled desktop managers
<clever> asymmetric: non-determinism in your filesystem
<clever> asymmetric: you need to set its enable to false
<clever> asymmetric: its enabled by default
<clever> asymmetric: you have the xterm desktop manager enabled
<clever> nhill: that tends to have its own issues, which includes a lack of plugin support
<clever> nhill: look for ExecStart and read that
<clever> nhill: read /etc/systemd/{system,user}/mpd.service and see what the cfg file says?
<clever> something=https://github.com/nixos/nixpkgs/archive/gitrev.tar.gz
<clever> pikajude: just add it to NIX_PATH
<clever> pikajude: does it need to be available to nix-env, or other nix tools?
<clever> __monty__: i think so
<clever> __monty__: should be safe to ignore
<clever> __monty__: toxvpn doesnt remove the routes when a friend goes offline, but still tries to re-add them when they come back online
<clever> yep
<clever> aiowej: the switch-to-configuration already changed the version of nix
<clever> aiowej: you then need to reboot
<clever> zacts: dont touch stateVersion
<clever> zacts: you add the new channel with nix-channel --add, as root
<clever> aiowej: thats odd, try /nix/store/g6sdlmldqzsr3rhxsdw98ahakl3hg471-nix-2.3/bin/nix-build '<nixos/nixos>' -A system && ./result/bin/switch-to-configuration boot
<clever> aiowej: can you pastebin it?
<clever> aiowej: yes
<clever> aiowej: try: _NIXOS_REBUILD_REEXEC=1 PATH=/nix/store/g6sdlmldqzsr3rhxsdw98ahakl3hg471-nix-2.3/bin:$PATH nixos-rebuild boot --fast
<clever> aiowej: it will install whatever version your channel is pointing to
<clever> aiowej: do: `sudo -i`, then nix-store -r /nix/store/g6sdlmldqzsr3rhxsdw98ahakl3hg471-nix-2.3 ; PATH=/nix/store/g6sdlmldqzsr3rhxsdw98ahakl3hg471-nix-2.3/bin:$PATH nixos-rebuild boot --fast
<clever> > "${unstable.nix}"
<clever> aiowej: one min
<clever> aiowej: you want to do the --update as root, not add another channel to non-root
<clever> aiowej: you first need to `nix-channel --update` to download the new package list, and probably dont need `nix-env -u`
<clever> aiowej: `nix-env -u` will only update things installed by `nix-env -i`, and only to the latest version in your current channel
<clever> waleee-cl: i believe it just tries them in order, until one works
<clever> symphorien: then it should respect that env var
<clever> dom```: if nix-daemon is in use, then its nix-daemon's env vars that matter
<clever> that would report only 1 channel
<clever> srhb: it reports the status of every channel
<clever> ,-A dom```
<clever> judson_: ah, not sure then
<clever> judson_: some modules in nixpkgs, put the options into a dedicated nix file, then import it in several places
<clever> yeah, sounds like it wont work
<clever> ah, not sure thats an option for options
<clever> judson_: mkMerge takes a list of sets
<clever> judson_: i think you want to use mkMerge, not //
<clever> alexarice[m]: you can also use `iftop` (it needs root) to see exactly which host is doing the traffic
<clever> alexarice[m]: nerdfonts is huge, check `vnstat -l` and see if its actually just downloading
<clever> yorick: sounds like it just failed to make $out
<clever> yorick: any messages above that?
<clever> almost to 200!
<clever> yeah, you need to modify it to call builtins.path, instead of filterSource
<clever> fresheyeball: where is the definition of gitignoreSource?
<clever> and the whole point of the filter function, is to act before things get copied to the store
<clever> neither one allows the inputs to be a storepath
<clever> you may need to patch gitignoreSource to use builtins.path instead
<clever> it functions identically to the filter from builtins.filterSource
<clever> which does both jobs at once
<clever> builtins.path { name = "source"; path = ./.; filter = something; }
<clever> fresheyeball: builtins.path accepts a filter argument
<clever> 2019-09-10 02:43:44 < clever> and path must have no dependencies (./. is allowed, "${hello}" isnt)
<clever> no attr is treated specially, they are just all hashed together
<clever> just simpler to implement that way
<clever> and the name of its src = /nix/store/hash-name; dir, is part of that hash
<clever> fresheyeball: the $out hash of a derivation, is just a dumb hash of every key=value pair inside the drv
<clever> if you force the same name in multiple places, and the contents match, then the hash should also match up
<clever> that will behave as-if the current dir has been renamed to "source" before copying it to /nix/store/hash-source
<clever> so, builtins.path { name = "source"; path = ./.; }
<clever> and path must have no dependencies (./. is allowed, "${hello}" isnt)
<clever> only path and name are required
<clever> which must contain a .path .name .filter .recursive. and .sha256
<clever> hmmm, builtins.path takes a set as the 1st argument
<clever> fresheyeball: PermitTTY in the sshd config, for the host that has no error
<clever> and its a problem with the server config, not the client
<clever> fresheyeball: i would expect there to be problems on the machines where you dont get that error
<clever> fresheyeball: then its doing its job
<clever> fresheyeball: can you pastebin examples of where it works and where it doesnt work?
<clever> fresheyeball: read the /etc/ssh/sshd_config file on each machine, how do they compare to line 51 of the above file?
<clever> fresheyeball: https://github.com/NixOS/nixpkgs/blob/release-19.03/nixos/modules/services/misc/nix-ssh-serve.nix#L51 this line prevents allocating a tty on the nix-ssh user
<clever> fresheyeball: are all of them on the same version of nixpkgs? are you testing with the nix-ssh user on each?
<clever> jlv: you want `import ./nixpkgs { overlays = []; }`
<clever> jlv: the `import ./nixpkgs {}` is likely loading the same overlay, causing infinite recursion
<clever> fresheyeball: the nix-ssh user is configured to never give a shell, and to directly run nix-store, so its more secure when the keyfile lacks a passphrase

2019-09-09

<clever> fresheyeball: for example, nix-build, ran inside a nix-shell, will use the shell based exprs
<clever> fresheyeball: i try to avoid lib.inNixShell, it causes things to behave in weird and unexpected ways
<clever> syd: $src will always be read-only, and by default, cp preserves permissions, so you need to `chmod -R +w` the dest after you copy
<clever> rawtaz: who needs state? :D
<clever> rawtaz: i call it reproducible!
<clever> rawtaz: i have some qemu setups configured to exit when you try to reboot, and then rollback the entire disk
<clever> rawtaz: in some cases, a machine cant boot while out of space, so id prefer fixing it without a reboot
<clever> fendor_: nix will think the files exist, when they dont, `nix-store --verify` will test for damage
<clever> fendor_: manually delete the tar with plain rm, then do --delete also
<clever> fendor_: try `nix-store --delete /nix/store/foo.tar.gz` ?
<clever> fendor_: try the --max-freed first?
<clever> fendor_: if not, you need to manually delete something non-nix first, then follow up with a small --max-freed
<clever> fendor_: `nix-collect-garbage --max-freed 1M` can sometimes work
<clever> sphalerite: i skimmed over it, and it looks good at a glance
<clever> eylusion: this work has already been done 3 or 4 times
<clever> eylusion: you may want to look at the existing minecraft package in nixpkgs, and copy that
<clever> and the shell script its using will instead not use kvm, if /dev/kvm doesnt exist
<clever> then it will think it has kvm support, and try the build
<clever> within the docker container
<clever> Ilya_G: edit /etc/nix/nix.conf to have the middle line i just pasted above
<clever> 2019-09-09 14:55:57 < Ilya_G> error: a 'x86_64-linux' with features {kvm} is required to build '/nix/store/02vqmq7lknz31gc5yx22qnvlfdzmx1pf-nixos-disk-image.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, nixos-test}
<clever> nix show-config | grep feature
<clever> system-features = benchmark big-parallel kvm nixos-test
<clever> Ilya_G: one min
<clever> or lie to nix about kvm support, and let the build performance suffer
<clever> your only option is to get a real linux host, to run the build
<clever> Ilya_G: but you cant use a vm in a vm, so qemu will never work for you
<clever> docker*
<clever> Ilya_G: the package is running linux in a VM for you, and then using the linux docket!
<clever> Ilya_G: technically, docker doesnt work on a mac, at all
<clever> Ilya_G: it wont work at all on a mac
<clever> Ilya_G: macos changes everything
<clever> Ilya_G: the driver must be loaded on the host, and docker must be configured to expose kvm to the container
<clever> along with kvm_amd or kvm_intel
<clever> Ilya_G: it should be created automatically when the kvm driver is loaded, modprobe kvm
<clever> crw-rw-rw- 1 root root 10, 232 Sep 7 03:35 /dev/kvm
<clever> Ilya_G: a character device
<clever> Ilya_G: nix is trying to boot a vm using qemu, which needs /dev/kvm to make it run faster
<clever> Ilya_G: you would have to configure docker to map /dev/kvm into the container
<clever> eylusion: it has to be added to the rpath of something with patchelf, check the nixpkgs manual
<clever> Ilya_G: you probably need to enable virtualizating extensions in your bios
<clever> Ilya_G: does /dev/kvm exist?
<clever> eylusion: its in here
<clever> > "${gcc.cc.lib}/lib/"
<clever> sphalerite: pretty big pr, but overall, it does look good
<clever> probably
<clever> __monty__: commented and merged
<clever> __monty__: ahhh, that would explain the problems
<clever> *looks*
<clever> codedmart: yeah, i have that in ~/.stack/config.yaml
<clever> codedmart: i think your only real option is to set it in ~/.stack/something
<clever> that works
<clever> user12343: you may need to either package kde3, or upgrade kpicosim to kde 5
<clever> yeah, even the 13.10 has kde4, and this is getting into the infancy of nix
<clever> even nixos 14.04 has kde4!
<clever> but thats a 3 year old version of kde
<clever> which is close...
<clever> nixos 16.09, under kde4.kdelibs, has a `kde4-config` binary
<clever> nixos-17.09 still has kf4-config
<clever> it might be a thing for older kde versions
<clever> user12343: it doesnt have a kde-config, just a kf5-config
<clever> kdebugdialog5 kf5-config
<clever> $ ls result//bin/
<clever> > kdeFrameworks.kdelibs4support.outputs
<clever> user12343: closest thing i can find
<clever> > kdeFrameworks.kdelibs4support
<clever> /home/clever/apps/nixpkgs/pkgs/development/libraries/kde-frameworks/srcs.nix: kdelibs4support = {
<clever> i dont see kde-config in any package...
<clever> user12343: what is the error it gives when saying it cant find kde-config?
<clever> ddima: fetchurl uses curl, not nix
<clever> ,locate kde-config
<clever> the server is sending a weird http header, which confuses nix-prefetch-url
<clever> content-encoding: x-gzip
<clever> ,tofu user12343
<clever> and re-add the sha256

2019-09-08

<clever> user12343: change line 6 to `fetchurl`
<clever> user12343: i think you just want nix-prefetch-url, without --unpack
<clever> user12343: can you pastebin the nix expr you have so far?
<clever> user12343: if you point src to a tar, mkDerivation will unpack it automatically
<clever> user12343: src = /path/to/local/dir or src = ./.;
<clever> 9 only obeys 1 overlay in the dir, but nix-env will obey all
<clever> only thing missing, is that line 9 should be mapping over readDir
<clever> infinisil: this will force nix-env to use the same overlays as nixo(p)s
<clever> overlays are cleaner
<clever> and that will effectively override every single package, to set withX to true
<clever> and due to how callPackage works, you can also use an overlay that sets `withX = true;`
<clever> and depending on what your doing, you can also use .override by itself
<clever> hpfr[m]: overlays still use .override
<clever> hpfr[m]: packageOverrides and .override can also do it, depends on the context
<clever> kim0: its the other way, that doesnt need tar in the path
<clever> ,tofu
<clever> the sha:
<clever> ,howoldis kim0
<clever> kim0: the rev can come from github, its just the current rev of the nixos-unstable branch on nixpkgs-channels, or from howoldis
<clever> kim0: unstableDir = (import <nixpkgs>{}).fetchFromGitHub { owner = "nixos"; repo = "nixpkgs"; rev = "the rev"; sha256 = "the sha256"; };
<clever> kim0: or use nixops
<clever> kim0: youlll need to use (import <nixpkgs>{}).fetchFromGitHub
<clever> kim0: the systemd service that runs nixos-rebuild must not have tar in PATH
<clever> kim0: with the metadata containing this cfg?
<clever> kim0: are you using nixos-install?
<clever> kraem: what command did you run to cause that error?
<clever> evanjs: nice
<clever> ,howoldis evanjs
<clever> evanjs: nixos-unstable-small is better for that, it updates faster, and still has testing
<clever> evanjs: best to use one of the channels, master can break things
<clever> > unstable.firefox.name
<clever> evanjs: it defaults to master, but you can also name a channel
<clever> what error did you get?
<clever> i would expect util-linux to fail with a clear error
<clever> no idea why one works and the other doesnt
<clever> > "${utillinux}"
<clever> > "${util-linux}"
<clever> > "${libuuid}"
<clever> PyroLagus: what error is it giving?
<clever> if you put util-linux into buildInputs, it will likely work
<clever> PyroLagus: nativeBuildInputs is only for build-time tools, headers wont be found in that list
<clever> PyroLagus: can you pastebin your expr?
<clever> /nix/store/ybncb8fp9xfvqw6axf58km865lxkdzv7-util-linux-2.29.2-dev/include/uuid/uuid.h
<clever> yes
<clever> PyroLagus: its an alias for util-linux!
<clever> > libuuid
<clever> fonts are a weird edgecase, where you expect to be able to configure it in one place, and every app obey
<clever> PyroLagus: careful, your about to invent docker!
<clever> kraem: behind the scenes, all `nixos-rebuild --upgrade` does, is run `nix-channel --update`
<clever> kraem: nix-channel --rollback
<clever> correction, 104 will source .xprofile, 112 will execute .xsession, so .xsession takes over the entire session
<clever> sessionCommands gets inserted on line 100, and line 112 will source .xsession
<clever> zeta_0: i would prefer sessionCommands
<clever> rndd: https://gist.github.com/cleverca22/8cae5bc9c02c12099a3bf5e20e75161f run `nix-build simple-test.nix` and then run `./result ./Aby_Elf_file`
<clever> rndd: you have to run patchelf on it to fix the interpreter
<clever> shadrach: yeah
<clever> shadrach: i believe nixops supports macos and azure
<clever> try listing how many cards are available
<clever> being built with cuda, and being able to talk to the drivers are seperate issues
<clever> shadrach: ive done cuda on nixos before, and when the hardware is meant for cuda, it works perfectly
<clever> yeah
<clever> shadrach: highly likely to run into problems
<clever> shadrach: ubuntu wont work either, you would have to either use the system cuda, or nixos
<clever> and the libraries have to match the version of the kernel
<clever> shadrach: pretty sure you have to be running nixos for the cuda to work, since it involves driver parts
<clever> shadrach: and where does it fail?
<clever> shadrach: what os did you run that nix-shell on?
<clever> shadrach: what does line 56 of that file say?
<clever> shadrach: your trying to build a linux kernel on darwin?
<clever> shadrach: the nix package likely hasnt been tested/fixed on macos
<clever> but if the dir itself is deleted (the -r in rm -rf), you get that back (as long as another snapshot wasnt made)
<clever> yeah, since you have snapshots on, deleting files will actually consume more disk space, as it creates new versions of the dir listing, to mark them as not in the dir anymore
<clever> iqubic: rm -rfv
<clever> and if you are below something like 5% free, writing anything is cpu intensive
<clever> also, in the case of zfs, when you remove a file from a dir, it has to write the new version of that dir listing to disk
<clever> zfs just does the hard work in the background, there is a garbage collector somewhere
<clever> ive heard that xfs has faster deletes for large files
<clever> simpson: ext3 i think also does that
<clever> simpson: and for some FS's the time to delete a file scales with the size of the file
<clever> Ashy: nix-build creates a result symlink pointing to the ... result!

2019-09-07

<clever> so it updates faster
<clever> yeah
<clever> multun: it takes a dozen hours to compile
<clever> yep, master has 69, and unstable is still 68
<clever> > firefox.name
<clever> gyroninja: and unstable-small JUST updated, but its using a commit that is 2 hours old
<clever> so unstable is 6 days behind master, and updated 1 day ago
<clever> so, 1 day ago, the commit from 6 days ago finished testing, and the channel updated
<clever> gyroninja: BUT, unstable is pointing to a commit from 6 days ago!
<clever> gyroninja: 1 day ago for unstable, 15 hours ago for 19.03
<clever> bikki[m]1: correct
<clever> infinisil: no entry for nixpkgs master?
<clever> > master.firefox.name
<clever> but the stable channels typically only get security fixes and browser updates, so they update much faster
<clever> so it can sometimes take longer for changes to go from master->unstable
<clever> bikki[m]1: because unstable is so unstable, it sometimes doesnt pass automated testing, which holds the channel back
<clever> when the user decides to manually run `upgrade-boot` in a root shell?
<clever> and you tell the user to enable the right one for their platform
<clever> samueldr: what if you just have nixos modules for each device, that install an upgrade-uboot script into systemPackages?
<clever> samueldr: yeah
<clever> romildo: .overrideAttrs (old: { setupHook = null; }) maybe
<clever> samueldr: that can make things more complex...
<clever> sphalerite: but thats just the config, does it also install the grub binaries?
<clever> sphalerite: ah
<clever> samueldr: it should probably use the same install-bootloader stuff that the rest of nixos uses, on x86
<clever> emily: the number mostly refers to the cpu, and the letter, the accessories (usb hub and such), the + is just a new version that is backwards compat
<clever> willghatch: its in the nix-index package
<clever> romildo: override the package to not make a setup hook
<clever> omnipotententity: ive configured my rpi's to netboot, without u-boot, but you have to burn a fuse to do it, and its very picky
<clever> willghatch: yes, lol
<clever> willghatch: buildFHSUserEnv isnt meant to be used for compiling, so it doesnt
<clever> willghatch: stdenv.mkDerivation will handle .dev for you
<clever> willghatch: i'm not sure if buildFHSUserEnv will properly work with gcc, have you tried libuuid.dev ?
<clever> ddima: ^^
<clever> ,locate
<clever> willghatch: nix-locate confirms that it should be in libuuid, can you pastebin your nix expr?
<clever> libuuid.dev 3,402 r /nix/store/ybncb8fp9xfvqw6axf58km865lxkdzv7-util-linux-2.29.2-dev/include/uuid/uuid.h
<clever> ,locate uuid uuid.h
<clever> ,locate uuid.h
<clever> i think the kernel is responsible for calling exit_boot()
<clever> xlibs*
<clever> for some weird reason, its in xlibx.libXi
<clever> xlibs.libXi.dev 36,014 r /nix/store/0k14cs4zyy7bl7r3r8hgc5nqp16f10aj-libXi-1.7.9-dev/include/X11/extensions/XInput.h
<clever> willghatch: xorg.xinput does not contain an XInput.h
<clever> ah
<clever> Acou_Bass: also have a look at security.acme.certs in the nixos options
<clever> mac10688: services.mysql.package only controls the version the systemd service runs
<clever> then just some $() and nix-diff
<clever> in my case, zero differences
<clever> /nix/store/4h2j1svqibv8qx468rqaypl5zvmrf64r-nixos-system-system76-19.09pre177651.aeb464dfd37.drv
<clever> [root@system76:~]# nix-instantiate -A system '<nixpkgs/nixos>'
<clever> warning: you did not specify '--add-root'; the result might be removed by the garbage collector
<clever> [root@system76:~]# nix-store -q --deriver /run/current-system
<clever> /nix/store/4h2j1svqibv8qx468rqaypl5zvmrf64r-nixos-system-system76-19.09pre177651.aeb464dfd37.drv
<clever> and then incrementally edit the config to null out the differences
<clever> omnipotententity: if you nix-diff the .drv for /run/current-system, and nixos-rebuild dry-run, you can see how your cfg differs from the running os
<clever> omnipotententity: nix-diff
<clever> sb0: they may exist, and i just didnt look hard enough
<clever> zeta_0: but there is the pmount program, that does most of the work, so you could modify xmonad to run pmount maybe?