<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>
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_: 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