2020-04-24

<clever> contrun[m]: nokaslr only helps if your using gdb and looking at addresses a lot
<clever> contrun[m]: then using qemu directly would be much simpler, one min
<clever> contrun[m]: and is this a VM?
<clever> it was a module, so it silently didnt even get loaded
<clever> contrun[m]: that error looks weird, like maybe you turned on something you shouldnt have
<clever> contrun[m]: and if this is a VM, you have much simpler options
<clever> contrun[m]: that would make the kernel huge, you want to figure out what is actually needed, and turn them on
<clever> contrun[m]: and if you build everything into the kernel, the module problem wont exist
<clever> contrun[m]: and change 23 to config.system.build.initialRamdisk
<clever> contrun[m]: then on line 17, change it to config. instead of netboot.config
<clever> contrun[m]: ah wait, keep 23 too, but change it some
<clever> contrun[m]: line 22&23 will copy a kernel and initrd to /boot, you would want to ditch 23, and modify 22 to use your special kernel
<clever> contrun[m]: then just dont tell nixos about it at all, tell grub to run the new kernel
<clever> contrun[m]: id just do what i did on the rpi then, compile a kernel with everything you need baked in, zero modules
<clever> yeah, like that
<clever> contrun[m]: try adding configfile = /path/to/config;
<clever> contrun[m]: try just boot.kernelPackages = pkgs.linuxPackages_latest.extend (self: super: { kernel = super.kernel.overrideAttrs (old: { src = /path/to/source; }); });
<clever> contrun[m]: what are you trying to make custom on the kernel?
<clever> contrun[m]: how did you build the custom packages? it shouldnt be this complicated
<clever> contrun[m]: /run/current-system/kernel-modules has the combined results and depmod caches
<clever> contrun[m]: nixos runs depmod later on, when its combining all module packages
<clever> just let flash die already? :P
<clever> iuunno27: if you fully quit firefox, then start it with that shell script?
<clever> iuunno: ~/.nix-profile/bin/firefox will be a shell script that exposes plugins to firefox
<clever> iuunno: firefox will only use the plugins that the wrapper shellscript exposes to it
<clever> iuunno: i would expect that to just work
<clever> iuunno: can you pastebin your entire home-manager config?
<clever> iuunno: and how did you enable flash in home-manager?
<clever> iuunno: and after you kill firefox, youve confirmed there is no firefox in `ps aux | grep fire` ?
<clever> iuunno: if home-manager is installing firefox, then it needs to configure all of the plugins
<clever> iuunno: definitely home-manager then
<clever> iuunno: what about `ls -l /home/otis/.nix-profile/bin/firefox` ?
<clever> iuunno: does `nix-env -q` list firefox?
<clever> then its installed into nix-env, either with -i or home-manager
<clever> iuunno: what does `type firefox` return when ran in a shell?
<clever> that will run python on a thing, generate some output, then read the output into nix
<clever> jlv38: builtins.readFile (runCommand "name" { buildInputs = [ python ]; } "python ${./foo.py} ${toString 1234} > $out")
<clever> jlv38: yep
<clever> iuunno: things like firefox and flash still get fixed in the release branches
<clever> iuunno: so it wont have anything that got added after march
<clever> iuunno: the nixos-20.03 channel is also a fork, based on what master had in march of 2020
<clever> ,ifd jlv38
<clever> jlv38: but IFD is probably a more sane option
<clever> jlv38: yeah, it would work from any nix expr
<clever> the only real difference is what tests have to pass before it updates
<clever> yeah, that lets you pull one thing from unstable, without changing the default
<clever> iuunno: then you could just undo that
<clever> iuunno: but you could also make just part of it use unstable, not all of it
<clever> ,unstable iuunno
<clever> not sure what part has to be modified
<clever> iuunno: you would need to modify something to use <unstable> instead of <nixpkgs>
<clever> iuunno: fairly normal, you could also have both channels on root
<clever> abathur: most irc clients have tab completion
<clever> jlv38: ^
<clever> abathur: it could also return a set containing multiple primops, to do diff things
<clever> abathur: internally, importNative runs a c++ function, which can return any nix type, including a custom primop that accepts N args, and runs another c++ func
<clever> abathur: this lets you run c++ code from a nix expr
<clever> {^_^}: no :P
<clever> ,importNative
<clever> abathur: builtins.importNative
<clever> to build whatever is in the default.nix of that repo
<clever> Fare: you could do `nix-env -f http://github.com/owner/repo/archive/rev.tar.gz -iA foo`
<clever> Fare: that would only work if your already in nixpkgs, and they have updated to that ver
<clever> Fare: so the user cant break things by running 17.03
<clever> Fare: i would make your default.nix always load a specific nixpkgs rev, and ignore <nixpkgs> entirely
<clever> Fare: and the channels for your user and root, are within those 2 symlinks
<clever> Fare: by default, ~/.nix-defexpr/ will contain all of your channels
<clever> mkIf just helps deal with infinite recursion when your getting into sticky areas
<clever> rotaerk: you can also use plain `if cond then val else val`
<clever> and that custom one could import <nixpkgs>
<clever> Fare: but this will add a custom foo, so you can nix-env -iA foo.hello
<clever> [clever@amd-nixos:~]$ cat ~/.nix-defexpr/test/foo/default.nix
<clever> import /home/clever/apps/nixpkgs
<clever> Fare: nix-env -f '<nixpkgs>' -iA foo, will look in NIX_PATH
<clever> Fare: nix-env -iA nixpkgs.foo looks in ~/.nix-defexpr/ not NIX_PATH
<clever> rotaerk: make the value of xkbOptions depend on virtualization.virtualbox.guest.enable
<clever> rotaerk: for that, i would just use lib.mkIf
<clever> rotaerk: mkForce can replace all other values, as with any other option
<clever> rotaerk: thats a special type, that will seperate every value with a ,
<clever> strings concatenated with ","

2020-04-23

<clever> if you use { runCommand, thingName }: at the top of a file you callPackage, then you can also foo.override { thingName = ...
<clever> then you can foo { thingName = "foo"; } to fill in the blanks
<clever> virus_dave: foo = { thingName }: runCommand "name" {} "${thingName} --foo"
<clever> virus_dave: make it into a function that takes a cmd name
<clever> gchristensen: i just leave a `sudo -i` open at all times
<clever> gchristensen: correct
<clever> ornxka: plus some extra files in the root, to say what git rev it came from
<clever> gchristensen: ive yet to mess with the zfs permissions
<clever> dmj`: pkgsStatic.libpqxx
<clever> then the default one maps to the new one
<clever> nerosnm: but its probably simpler to just make a dummy configuration.nix, that just does: { imports = [ /home/soren/configuration.nix ]; }
<clever> nerosnm: you probably want nixos-config=/home/soren/configuration.nix
<clever> nerosnm: that tells it to search for things inside the DIRECTORY /home/soren/configuration.nix

2020-04-22

<clever> ramses_: i was thinking just a normal container, start vs exec
<clever> ramses_: i was thinking a docker container with state that can persist, so nix can cache things
<clever> guts: thats what --install-bootloader manages, as long as the right thing is mounted to /boot
<clever> guts: you may want `nixos-rebuild --install-bootloader`
<clever> guts: just fix the config, mount the right thing to /boot, and nixos-rebuild
<clever> guts: if your trying to change the /boot for the running os, you dont want nixos-install
<clever> cole-h: either patch the scripts, or wrapProgram
<clever> cole-h: when you run strings on it, what paths do you see to the things it wants to run?
<clever> cole-h: is the final bin/fish a shell script or a binary?
<clever> ,runtimedeps cole-h
<clever> cole-h: which is how i would do things
<clever> cole-h: that entirely ignores the propagatedBuildInputs, and just inserts an absolute path into the code
<clever> ramses_: and now try loading the docker image and see if its usable
<clever> cole-h: there may be other things that are making it behave in a non-normal way
<clever> ,ifd armin
<clever> armin: builtins.readFile (pkgs.runCommand "name" {} "echo stuff > $out")
<clever> cole-h: you want to use wrapProgram
<clever> cole-h: under normal conditions, propagatedBuildInputs only appear in other builds, and never at runtime
<clever> ramses_: you can likely also remove a lot of the things in that list
<clever> ramses_: you can then use `nix why-depends ./result /nix/store/hash-glibc-locales` to find out why something is included, and begin adding overrides to make it not be included
<clever> ramses_: that will tell you how big the closure is, and what is making it so big
<clever> ramses_: then you can build it, and: du --apparent-size -h --max=0 -c $(nix-store -qR ./result ) | sort -h
<clever> ramses_: if you just generate a text file containing all of the paths: https://gist.github.com/cleverca22/4f172a8da8d2080094db0969e5e439d2
<clever> ramses_: 300mb, if i ignore my zfs compression
<clever> ramses_: adding that into the mix raises it to 200mb, how did you measure 600?
<clever> energizer: if thats a fifo, it may screw things up, it might also change the seek position of the file and screw it up
<clever> ramses_: can you also include the default.nix file? the other stuff only totals to 142mb
<clever> ramses_: one min...
<clever> <nixos/nixos> and <nixpkgs/nixos> are the nixos subdir of that channel
<clever> cole-h: the other way around, <nixpkgs> is an alias to the channel called nixos on root, which is what <nixos> maps to
<clever> energizer: <nixos> is a side-effect of `/nix/var/nix/profiles/per-user/root/channels` which just exposes every channel root has
<clever> energizer: there is no nixos=
<clever> ivegotasthma: nope, thats <home-manager/nixos> the nixos subdir of <home-manager>
<clever> on a default setup, <nixos> and <nixpkgs> point to the same thing
<clever> energizer: when you want to refer to a specific channel, and you can use any channel you have added like that
<clever> probably
<clever> thats why its there
<clever> ivegotasthma: that will break anything that does import <nixpkgs> {}
<clever> ivegotasthma: because there is a nixpkgs= in $NIX_PATH
<clever> it could be a design flaw of `nix search`
<clever> id expect that to not have any duplicates, but ive not used the new `nix search` much
<clever> ivegotasthma: and what is the output from those 2 commands,without root?
<clever> ivegotasthma: what does `echo $NIX_PATH` say?
<clever> ivegotasthma: `sudo -u foo command` to run something as somebody
<clever> ramses_: so you can just `docker load < result/something.tar.gz` from within docker itself
<clever> ramses_: docker also has a way to map its unix socket into a container
<clever> ramses_: on windows and darwin, docker just runs a linux VM, and then runs plain linux docker within that
<clever> ramses_: id say they should all just use a standard "dev environment" based on docker, and nix will already be available in that
<clever> ramses_: ack!, the nix+docker build process only really works on linux
<clever> ramses_: linux or darwin?
<clever> ignore the docker tooling as much as possible!
<clever> then just build it like normal, using nix
<clever> ramses_: and use docker volumes to sneak the final .tar.gz out to the host
<clever> ramses_: i would just manually launch an interactive docker shell into a container that has nix
<clever> ramses_: or you can just go nuts and use dockerTools.buildLayeredImage, which dynamically generates as many layers as you want (but you have less control of the borders)
<clever> ramses_: or you can move to step 2, lines 95-102 create a 2-layer image, with some more binaries in the 2nd layer (so you can reuse the 1st layer on future `docker pull`s)
<clever> you can either just stop there, and put everything you want into that image
<clever> ramses_: lines 74-92 creates a docker image with the listed tools
<clever> ramses_: you could run nix in docker to build a docker image
<clever> ramses_: dockerTools.buildImage lets you directly build a docker image, with only the things you want
<clever> ramses_: nix can generate docker images directly
<clever> ramses_: what does rm -rf say?
<clever> ramses_: its probably safe to rm -rf it, in this case
<clever> ramses_: then any garbage collection should get rid of it, with no arguments
<clever> ramses_: what does it report?
<clever> ramses_: run `nix-store --query --roots` on the given path
<clever> infinisil: 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> cole-h: i think so
<clever> cole-h: $out is set during every phase
<clever> infinisil: yeah, you can point nix-channel to a rev
<clever> cole-h: substituteInPlace
<clever> freeman42x[m]: yeah, thats my github user
<clever> numkem: wrapProgram
<clever> infandum: grep
<clever> infandum: the source code for the R program
<clever> not sure then
<clever> infandum: does the string "/usr/lib/R/library/stats/libs/stats.so" appear anywhere in the source?
<clever> kitemikaze: lib.mkForce can override any nixos option
<clever> infandum: its only a runtime dependency if the /nix/store/hash-stats path appears within the final output of your build
<clever> infandum: you need to patch it to look i the right place, buildInputs dont magically appear in /usr/lib, /usr/lib just never exists
<clever> qy[m]: in this case, i would just run `make` inside `nix-shell` most of the time
<clever> qy[m]: and because its all one derivation, changing any file rebuilds all of them
<clever> qy[m]: yeah, thats harder to split up
<clever> qy[m]: next time it builds a given library twice, record each .drv file, and run nix-diff on the pair, to see why it rebuilt it
<clever> qy[m]: i just break the project up into smaller shared libraries, and put each into its own drv
<clever> qy[m]: it only really works in nix-shell or if your allowing massive impurities into the sandbox
<clever> jackdk: like that
<clever> [nix-shell:~]$ cat $NIX_CC/nix-support/dynamic-linker
<clever> /nix/store/qb6k4hp7gk331x9fydw0w7qj4dv09bwz-glibc-2.27/lib/ld-linux-x86-64.so.2
<clever> jackdk: you want to use the $NIX_CC env var in a nix-shell
<clever> jackdk: ldd forces a certain interpreter
<clever> jackdk: also, `sorbet-static` ... `dynamically linked`, it lies!!
<clever> jackdk: thats not been fully patched
<clever> jackdk: yep, interpreter /lib64/ld-linux-x86-64.so.2,
<clever> jackdk: what does `file` say about the given binary? ldd wont show the most important part
<clever> you want something like nix-user-chroot then
<clever> oh
<clever> Kyndig: unstable should be cached by hydra
<clever> jackdk: you need to stop it from trying to download an llvm
<clever> jackdk: that will just fail, because any llvm it downloads wont be patched correctly
<clever> jackdk: you can probably just patch it in the 2nd derivation, without any IFD
<clever> jackdk: youll need to find flags for bazel to force it to do that
<clever> jackdk: tell bazel to download only, patch it, then tell it to run things
<clever> jackdk: /usr/bin/env doesnt exist in the sandbox, you have to run patchShebangs on it
<clever> jackdk: what is the #! in that file?

2020-04-21

<clever> mokasin: remove the serviceConfig on line 3, and use pkgs.jq not "jq"
<clever> mokasin: https://nixos.org/nixos/options.html#systemd.services.%3Cname%3E.path
<clever> mokasin: you have .path at the wrong spot
<clever> mokasin: can you paste the nix code your currently trying?

2020-04-19

<clever> energizer: builtins.trace
<clever> not a problem
<clever> stevenxl: on line 19-24
<clever> stevenxl: you need to add hastory-data-cli to the list in overlay.nix
<clever> stevenxl: or just link to it on github, heh
<clever> stevenxl: and overlay.nix ?
<clever> stevenxl: line 2 is loading a pkgs.nix file
<clever> stevenxl: and the pkgs.nix file?
<clever> stevenxl: can you pastebin the default.nix file?
<clever> stevenxl: is it in hackage? did you update the cabal file recently? change nixpkgs?
<clever> stevenxl: and if your not creating it with an override and another cabal2nix, it wont be found
<clever> stevenxl: it sounds like cabal2nix wants a package named hastory-data-cli
<clever> ,libraries fabianhjr
<clever> henry_: probably
<clever> henry_: just `nix-env -iA nixpkgs.nix` and that should fix it
<clever> henry_: that would be the problem then, you have to compile nix with nix, to make the default sandbox-paths work right
<clever> henry_: oh, was nix built by nix, or something else?
<clever> and it looks like it might be static now, which should fix all of that?
<clever> henry_: there should be an entry something like this
<clever> sandbox-paths = /bin/sh=/nix/store/nfpnmpi5qc3dqjc50awf9c7nbr87yp18-busybox-1.31.1-x86_64-unknown-linux-musl/bin/busybox
<clever> $ nix show-config | grep sh
<clever> cole-h: and the existing service entry already copies things
<clever> henry_: the only real solution is to use a binary cache for that step, or use a different nixpkgs from the host
<clever> henry_: if your trying to build the glibc that /bin/sh depends on, things fail hard
<clever> cole-h: either patch libvirtd to look in a diff place, or use a prestart script on the libvirtd service
<clever> cole-h: why does it need to be there?
<clever> cole-h: depends on why it needs to be there and when
<clever> but if your building that glibc, it gets omitted, and the sh fails hard
<clever> and the entire closure of that (including a glibc) get added to the sandbox
<clever> henry_: when the sandbox is on, nix adds an impure /bin/sh to the sandbox, due to system() in glibc
<clever> henry_: are you disabling the binary caches?
<clever> just import what you wanted to begin with, skip the searching for it!
<clever> nix-env -E '_: import ./. {}`
<clever> but at that point, you can just skip the search path
<clever> nix-env -I nixpkgs=whatever -E '_: import <nixpkgs> ...
<clever> turion: you can still use -I
<clever> yes, its confusing, just use config.nix or nix-shell
<clever> turion: so you want something more like `nix-env -E 'channels: (import channels.nixpkgs {}).agda`
<clever> turion: `nix-env -E ...` will pass you a set, containign the path to each channel
<clever> genevino: that should explain the basics and how derivations work
<clever> ,pills ?
<clever> ,nix-pills genevino
<clever> the nginx rootDir is set to a derivation, that contains 2 images and an index.html
<clever> genevino: here is another more complex example
<clever> genevino: the path is based on a hash of the build directions
<clever> genevino: all derivations have a $out
<clever> genevino: pkgs.runCommand "rootdir" {} "mkdir $out ; cp ${./index.html} $out/index.html" for ex
<clever> genevino: what i do, is i point nginx to a derivation
<clever> jlv: i believe mkOverride only works at the root of the types.attrs node
<clever> ah
<clever> jlv: i think submodules have their own config and options trees
<clever> jlv: like so?
<clever> > lib.attrByPath [ "a" "b" ] "default" { a.b = 3; }
<clever> jlv: like so?
<clever> nix-repl> options.services.mysql.enable.type
<clever> { _type = "option-type"; check = «primop»; description = "boolean"; functor = { ... }; getSubModules = null; getSubOptions = «lambda @ /root/.nix-defexpr/channels/nixos/lib/types.nix:70:23»; merge = «lambda @ /root/.nix-defexpr/channels/nixos/lib/options.nix:108:22»; name = "bool"; substSubModules = «lambda @ /root/.nix-defexpr/channels/nixos/lib/types.nix:75:25»; typeMerge = «lambda @ /root/.nix-defexpr/channels/nixos/lib/types.nix:23:25»; }
<clever> [root@amd-nixos:~]# nix repl '<nixos/nixos>'
<clever> energizer: that sounds like its better done in a normal program you run at activate time, not at eval time
<clever> ,xy energizer
<clever> energizer: what is your end-goal
<clever> energizer: you would need to recursively call readDir on each dir you see
<clever> but all of that rot is confined to the nix files, rather then scattered over the whole machine
<clever> notgne2: enless you discover a 2 year old override thats forcing the gradle version, and has been sitting unused in config.nix for ages
<clever> energizer: builtins.readDir ./.

2020-04-18

<clever> [3~
<clever> NobbZ[m]: try forgetting a } in c!
<clever> Xe: 20.03 is based on a recent fork of unstable
<clever> thats probable
<clever> Xe: maybe, running `diff -r` would explain what
<clever> Xe: if you invalidate the hash (replace in a few 0's), it should re-download things and give a new hash
<clever> what is differing?
<clever> Xe: make a copy of the directory that hash is for, and then try running diff -r against the 2 versions of it
<clever> Xe: can you pastebin the nix expression?
<clever> ornxka: any errors above that?
<clever> ornxka: not sure what else to check then
<clever> ornxka: and the exact hash it says, exists there?
<clever> ornxka: does the systempath config in /proc/cmdline exist in the nix store you mounted?
<clever> numkem: the asar files are basically just a tar to hold html/js/css, and you can run the nixpkgs electron against it
<clever> numkem: what i would do, is to just delete all of the binaries, and run ${pkgs.electron}/bin/electron, which is already patched
<clever> and without debug info, it can be tricky to backtrace
<clever> but at this point, the stack is more important
<clever> numkem: you can just manually substract some from the number, and paste it where $eip was
<clever> numkem: even gdb doesnt know what the opcode is!, definitely sounds like it just jmp'd to a random address and is crashing hard
<clever> numkem: ` x /5i $pc` ?
<clever> numkem: `x /5i` ?
<clever> numkem: one min
<clever> numkem: what about `disass`
<clever> energizer: and yeah, the /etc stuff will track what it made, and clean up after itself
<clever> energizer: not really, when you remove the activation script, it just stops running and forgets about it
<clever> bifunc2: its nvme only, so legacy boot cant even see the drive
<clever> bifunc2: only issues was figuring out uefi install for the first time