2017-06-24

<clever> -n, --line-number
<clever> grep can also do that
<clever> which is enabled on most distros, via an alias, but not on nixos
<clever> grep also has --color
<clever> "function wrapProgram" only found <function>wrapProgram
<clever> yeah, but the only documentation is the source
<clever> and neither can search.nix.gsc.io, odd
<clever> it cant find the definition of wrapProgram
<clever> and once again, github search fails

2017-06-23

<clever> and then its imposible to upgrade
<clever> and even then, you must ensure zero references to ghc at runtime, or the 2nd nixos wont fit
<clever> Infinisil: so it would have to be a nixops target
<clever> remote build slaves wont do, since nix wants to download the deps to the local box, then push it out to slaves
<clever> a single copy of ghc would consume over 25% of the disk space
<clever> i had to disable Xorg and fully GC it, before it could finish a nixos-rebuild
<clever> i have a netbook with nixos that barely has enough room for 2 generations of nixos
<clever> but not everyone can afford to waste space like that, lol
<clever> Infinisil: and i think i have 7 copies of ghc 8 on mine
<clever> gcc and c/c++ would be cheaper, but then you run the risk of segfaults
<clever> Infinisil: only cost is the 1gig you need just to install ghc
<clever> and if i do it too fast on windows with putty, it misses keystrokes
<clever> i often hammer out complex sequences of control codes in screen, using ctrl and shift
<clever> oh yeah, and windows cant even keep up with my typing speed, lol
<clever> i suspect it was forcing a vsync between every line of text, or possibly every character
<clever> because of that, xterm framerates where horid, "ls -ltrh" took minutes to output
<clever> so nixos kept using the outdated repo, that had been long forgotten
<clever> but the auto-generated stuff in xorg packages, just got an http dir listing, and built everything in it
<clever> one of the components in the mesa pathway, was merged into another project
<clever> i also discovered some unique nixos problems with the open-source drivers before
<clever> yeah
<clever> and xfce restores dual-monitor upon login, crashing xorg hard
<clever> the closed-source driver is worse, any attempt to turn on dual-monito crashes xorg hard
<clever> so i must be very carefull near the video cables
<clever> and X also likes to auto-activate any monitor i hot-plug
<clever> i believe this is the open source one, the only other crippling fault it has, is that Xorg crashes hard if i unplug an active monitor
<clever> 376 videoDrivers = [ "ati" ];
<clever> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XTX [Radeon R7 260X/360]
<clever> and junk from a previous reboot was in there
<clever> because it rendered the buffer before xfce had loaded the image
<clever> but another strong piece of evidence, the WINDOWS wallpaper was visible on the XFCE desktop after a reboot
<clever> yeah, the lines are blurred a bit
<clever> i believe
<clever> Ralith: because it happens to every app with tooltips
<clever> but that site doesnt make it possible to just hide a tooltip, it constantly changes it as you move the mouse
<clever> no compositor
<clever> i have to hide, and then re-show the tooltip
<clever> sphalerite: my gpu seems to paint the tooltips before the pixel data has been filled in, so it always paints garbage on the 1st try
<clever> sphalerite: the tooltips on that site are nearly unusable due to bugs in my gpu driver!
<clever> ah, sounds different then
<clever> the gpu process alone is using 1.3gig
<clever> sphalerite: at least in chrome, i can open the chrome task manager, and see the usage for every process, and which tabs are tied to it
<clever> sphalerite: ive been having a lot of tab crashes in chromium lately, when they get to 1 or 2gig of usage, the process just implodes on itself
<clever> chrishill: and are you installing chromium?, nix-env -iA nixos.chromium
<clever> you have to call the function with arguments before you can access the packages within
<clever> nixpkgs = import <nixpkgs> wont work, because that returns the function at the top of nixpkgs
<clever> justanotheruser: you have to load nixpkgs with either nix-repl '<nixpkgs>' or by running :l <nixpkgs> in nix-repl
<clever> chrishill: you need to set chromium.enableWideVine = true; in your nixpkgs config
<clever> justanotheruser: with what command exactly?
<clever> what did you do to set nixpkgs?, it doesnt exist by default
<clever> this works for me
<clever> nix-repl> builtins.attrNames nix-zsh-completions
<clever> *doh*, i have super and self backwards in my example
<clever> simendsjo: haskellPackages = haskellPackages.override (super: self: { ghc-syb-utils = pkgs.haskell.lib.overrideCabal super.ghc-syb-utils (drv: { doCheck = false; }); }); i think
<clever> simendsjo: there is also haskellPackages.override which handles internal references to ghc-syb-utils for you
<clever> simendsjo: which overwrites the entire haskellPackages set, with a new one containing just a single attribute
<clever> simendsjo: haskellPackages.ghc-syb-utils = doesnt work in an obvious way, it does haskellPackages = { ghc-syb-utils = ...; };
<clever> and i wouldnt really use a blockchain as a replacement for ntp, the resolution is far lower
<clever> yeah, you would need to eventualy hear about the other fork and correct things, or hard-code a minimum difficulty for the chain to be acceptable
<clever> and also, the time it took you to make that 1 block will set you behind time wise a decent amount, until you can get the difficulty down enough to cheat and make more blocks then you should
<clever> i believe there is also another point, that when given 2 chains of the same length, prefer the chain that has had a higher difficulty
<clever> MichaelRaskin: you would need to partition the entire internet nearly 50/50 by hashing power
<clever> MichaelRaskin: but with the difficulty of the chain as high as it is, any partition is going to suffer so badly it wont progress at all
<clever> this will pass it python3, under the attribute name python2
<clever> ison111: mod_wsgi.override { python2 = python3; };
<clever> see the above link
<clever> so you need to configure apache, so it configures mod_wsgi correctly
<clever> but its failing at runtime, not build time
<clever> ah
<clever> i have a feeling that you need to instead modify the pythonpath within apache
<clever> ison111: what are you expecting it to do?
<clever> but, will adding pillow to the buildInputs actually affect the build?
<clever> ah, that looks like it should have worked
<clever> ah, can you gist the contents of configuration.nix?
<clever> what command did you run?
<clever> ison111: how did you try building the package?
<clever> yep
<clever> isnt that flexible
<clever> you have to run the same version on both ends
<clever> yeah
<clever> some of my servers only have one or the other, and many of them rename the binary to remove the ver number
<clever> main issue ive run into, is v2 vs v3
<clever> this is an example i had throw together many months ago
<clever> justanotheruser: you would need a seperate derivation for every step, and then link them all up in nix
<clever> Infinisil: ah, networking.extraHosts is the cheap way
<clever> Infinisil: services.bind.enable = true; is all you need, lol
<clever> causing things to just fail in wonky ways, because it had no v6 addr
<clever> and have set it up for somebody else recently, their router was returning ipv6 results for an ipv4 query
<clever> i run my own recursive caching server, on nixos
<clever> yeah
<clever> Infinisil: oh, maybe thats why ive been seeing weird dns issues on this end
<clever> gcc will just set the right headers from the start
<clever> so you have to set LD_LIBRARY_PATH when running it
<clever> justanotheruser: for both python, and java, you cant patchelf the RPATH of the elf file, because its an input, not your output
<clever> justanotheruser: because python is strange
<clever> justanotheruser: you need to wrap the shell script that runs python3 on the python file
<clever> justanotheruser: you need to add the ${freetype}/lib/ to LD_LIBRARY_PATH
<clever> justanotheruser: nope
<clever> ison111: did you use overrideDerivation or overrideAttrs?
<clever> ison111: which override method did you use?
<clever> or it will never use it
<clever> you have to pass it into the panda3d derivation somehow
<clever> how did you pass it to panda3d?
<clever> where did you specify freetype?
<clever> justanotheruser: did you install freetype with nix-env?
<clever> jbaum98: and also, configuration.nix itself is a nixos module
<clever> jbaum98: just put it into the imports list of configuration.nix
<clever> a mac guest in a VM would be harder
<clever> then you can build for either platform, while booted into mac
<clever> or flag a linux VM as a linux build slave, so the mac can still do linux builds
<clever> but in your case, you could do it from a linux VM inside the mac
<clever> in my case, i dont own any mac hardware, so i use www.macincloud.com
<clever> this will force it to build a darwin version, ignoring the current host
<clever> then you can do nix-build '<nixpkgs>' -A foo --argstr system x86_64-darwin
<clever> the first 2 options
<clever> then configure nix.buildMachines on your nixos box
<clever> ensure nix is in the $PATH on non-interactive shells (try ssh mac "nix-store --help")
<clever> another fun thing to setup, is darwin build slaves
<clever> so you could prevent nix from building the package on arm, or darwin
<clever> which restricts where nix will even try to build it
<clever> and if hydraPlatforms is missing, it defaults to meta.platforms
<clever> then it can be in the main attribute list as foo-unstable, but not pre-built
<clever> and if its an empty list, none
<clever> that controls which platforms hydra will build it for
<clever> you can also just set meta.hydraPlatforms
<clever> but there is no way to make nixpkgs always build from master
<clever> some packages have a foo and a foo-unstable attribute
<clever> :D
<clever> if includeGUI then (buildEnv { name = "foo-with-gui"; paths = [ cli gui ]; } else cli
<clever> and that 3rd one could just return the un-modified cli in the false case
<clever> yeah
<clever> chrome and firefox plugins work in a similiar way
<clever> that operation is fast, so it can be re-built on the end-users machine
<clever> that will conditionaly merge the cli and gui (either outputs, or seperate packages)
<clever> but you could then make a 3rd package, using buildEnv and arguments
<clever> and always remove the pre-existing one
<clever> the tricky thing there, is that nix-env will think one is an upgrade for the other
<clever> that can be done, but would possibly result in having to recompile it, if the binary cache doesnt have both variants
<clever> so it uses up less disk space
<clever> and then it wont depend on things like libX11
<clever> but if you only install foo.out, the gui can be deleted by a GC
<clever> it will only be in path if you install foo.gui and foo.out at the same time
<clever> c: make 2 packages, which it sounds like youve done already
<clever> b: make a single package that builds both, but puts the gui stuff in the $gui output, via outputs = [ "out" "gui" ];
<clever> a: make a single package that just builds both and puts them into $out
<clever> so i just use nix on all of my old gentoo boxes
<clever> ive given up on installing things with emerge on gentoo, its too slow, but i cant always change the os right away
<clever> ah

2017-06-22

<clever> slabity_: try adding "${mozillaPkgs}/rust-overlay.nix" to the overlays list
<clever> i dont think the overlay is meant to be ran thru callPackage
<clever> slabity_: mozillaOverlay does not contain an overlay, and it depends on the value of pkgs
<clever> can you gist your config?
<clever> 2017-06-22 20:22:37 < clever> slabity_: otherwise, it will have a circular reference, where the value of pkgs depends on the overlays, which depend on pkgs.fetch...
<clever> 2017-06-22 20:22:06 < clever> slabity_: you may need to use (import <nixpkgs>{config={};}).fetchFromGithub
<clever> yeah
<clever> i havent used them before, but you can configure a list of overlays somewhere
<clever> or possibly directly to the overlays list
<clever> passed to either callPackage or import, depending on what arguments it needs
<clever> "${mozillaPkgs}/rust-overlay.nix"
<clever> MP2E: so if you can ssh in either direction, you can get the copy to work
<clever> MP2E: there is both --from and --to, to let you switch the direction its moving the package
<clever> simpson: you can probably alter PS1 in the shellHook
<clever> slabity_: try adding --show-trace, and figure out which file is complaining
<clever> what repo did you give to fetch from github?
<clever> slabity_: i dont think callPackage is the right thing to use there
<clever> i just open nix-repl '<nixpkgs>' and tab-complete fetchFrom
<clever> i can never remember which way it goes and used your question as an example
<clever> slabity_: and the H in Hub has to be in caps
<clever> just dontBuild = true;
<clever> Infinisil: oh, and i found a better answer
<clever> Infinisil: set buildPhase=":"; which causes bash to just do nothing for some reason
<clever> slabity_: otherwise, it will have a circular reference, where the value of pkgs depends on the overlays, which depend on pkgs.fetch...
<clever> slabity_: you may need to use (import <nixpkgs>{config={};}).fetchFromGithub
<clever> simpson: ah, then you would want the file to return an attribute set of those runCommandCC's, and use -A to switch between them
<clever> simpson: you can also optionaly add { arg1 ? "defaultval" }: and then use "--argstr arg1 foo" to change it
<clever> simpson: make a shell.nix containing this: with import <nixpkgs>{}; runCommandCC "dummy" { buildInputs = [ foo bar baz ]; } ""
<clever> and will probably also work on linux
<clever> the sed answer looks much cleaner
<clever> ah, didnt think about tail with a +
<clever> sed?
<clever> all it did was remove support for /lib/alsa-lib/
<clever> nope
<clever> did it also put a usage elsewhere?
<clever> the commit that added the patch
<clever> this also gave me an idea
<clever> my /etc/asound.conf has an =, and also a libs
<clever> libs.native = /nix/store/wlnf10p7pcd244qzxlpqdqlgirkcyizj-alsa-plugins-1.1.1/lib/alsa-lib/libasound_module_pcm_pulse.so ;
<clever> pcm_type.pulse {
<clever> oh
<clever> what does the config look like?
<clever> enless there are config files that already comtain things like id=open and id=comment
<clever> so libs=/path/to/libs
<clever> i think id, is the thing to the left of the =
<clever> it appears to modify the parsing of an existing config file that alsa-lib already reads
<clever> so we need to see the original source its patching, and find out what that loops over
<clever> it adds a check if the id variable is "libs"
<clever> yeah
<clever> jbaum98: the patch is already referenced in the alsa-lib build
<clever> pkgs/os-specific/linux/alsa-lib/default.nix: ./alsa-plugin-conf-multilib.patch
<clever> then create a wrapper that merges the chosen plugins, sets the right variables, and then makes the right wrappers/configs
<clever> it would need to be patched to either look in a directory relative to home, in /etc, or in a directory set in an env variable
<clever> thats a circular reference, nix doesnt allow it, ever
<clever> ah
<clever> jbaum98: "${pkgs.hello}/bin/hello"
<clever> jbaum98: if you just want the output of some other derivation, use that derivations value
<clever> sphalerite: toString prevents it from being copied to the store
<clever> but nix wont use the stuff you manually compiled
<clever> CcxWrk: nix-shell will create an env with things setup
<clever> sphalerite: i tend to use this: du --max=0 -hc $(nix-store -qR /run/current-system) | sort -h
<clever> nix-env -f ~/apps/nixpkgs -iA hello
<clever> bbl
<clever> Gravious: and yeah, GC may have trouble deleting it
<clever> Gravious: the next time you run a command like nix-store --verify, it will get upset and want to fix it
<clever> nix-shell does change PS1 to say its a nix-shell shell
<clever> and insert that derivation into systemPackages
<clever> ambro718: then you need to make a derivation using runCommand, that creates a $out/bin/foo symlink pointing to ${hello}/bin/hello
<clever> Gravious: under nixos, a script on bootup creates setuid wrappers in /run/wrappers/bin
<clever> Gravious: yeah
<clever> ambro718: anything you add to environment.systemPackages will get merged into that
<clever> ambro718: which bin directory?
<clever> Gravious: and setuid stuff requires nixos, it just doesnt work on other distros
<clever> Gravious: nix-env without -A, will search every derivation in every channel
<clever> Infinisil: ah, yeah, nix doesnt like you doing static linking
<clever> and it will put the 2 git repos into the nix-path
<clever> this will clone 2 git repos, then call release.nix in notos, and pass it all 3 inputs as arguments
<clever> here is an example of how the config should look
<clever> catern: is your hydra gui publicly visible?
<clever> it doesnt just give you a set of boxes
<clever> but unlike the gui, you need to know what fields to fill in
<clever> the new method just generates the same config in a json blob, using another nix expression
<clever> you give it the name of a nix file, and which input its in
<clever> the old method, was to configure the jobset within the hydra gui
<clever> i would have expected that one to be excluded from the restricted mode
<clever> thats part of the internals of nix, that every derivation uses
<clever> that error is weird
<clever> what is the exact error?
<clever> catern: look at each of the services in the hydra module
<clever> nixy: boot.kernelPackages = pkgs.linuxPackages_4_9; for example
<clever> that will create a new version of hello, with libfoo in the inputs, then load it as a shell
<clever> nix-shell -E 'with import <nixpkgs> {}; hello.overrideAttrs (old: { buildInputs = old.buildInputs ++ [ libfoo ]; })'
<clever> jbaum98: you need to use -E and overrideAttrs
<clever> jbaum98: -p generates a derivation on the fly, so it cant be used with other derivations
<clever> nixy: journalctl -f -u display-manager
<clever> Infinisil: i would just find out what it expects in there, and stick an echo into the nix file, and reuse the variable passed to fetchgit
<clever> nixpkgs removed the .git
<clever> but git describe wont work
<clever> Infinisil: i think they want you to run this to generate it
<clever> /nix/store/9nv14d8v56m1ycn4dk2bmhbx2cjf6rd8-scyther-v1.1.3-src/src/describe-version.py: fp = open('version.h','w')
<clever> Infinisil: it still fails, but over half of it compiles
<clever> [ 65%] Building C object CMakeFiles/scyther-linux.dir/switches.o
<clever> /tmp/nix-build-scyther-1.1.3.drv-0/scyther-v1.1.3-src/src/switches.c:40:21: fatal error: version.h: No such file or directory
<clever> but its not been split up yet, so it needs to use pkgs.pkgsi686Linux
<clever> idealy, you would use callPackage_i686 when loading this file
<clever> Infinisil: scyther also forces the build to 32bit mode
<clever> 12 set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -static -m32")
<clever> Infinisil: scyther looks for its junk in the current dir, not the dir of the cmake files
<clever> nix will make a build directory, cd into it, then run cmake ..
<clever> scyther broke a key feature of cmake, out of tree builds
<clever> yep, thats it
<clever> Infinisil: oh, i have a thought
<clever> but that doesnt fix it
<clever> Infinisil: reading the cmake source, if target isnt set, it defaults to the current host
<clever> then you can see everything that bash does
<clever> it may also help to do "set -x" before you configure
<clever> and you may need a postUnpack hook to append a src to it
<clever> after unpackPhase, you need to cd into $sourceRoot
<clever> and it obeys cmakeFlags, so thats a good place to put the -D's for cmake
<clever> or just skip directly to cmakeConfigurePhase, since you know its there
<clever> so you need to test for the variable, and eval it
<clever> but confusingly, the configurePhase function remains
<clever> line 63 sets $configurePhase to cmakeConfigurePhase
<clever> Infinisil: this file will be sourced by $stdenv/setup, and it will mutate the stdenv some
<clever> Infinisil:

2017-06-21

<clever> Infinisil: let me also link the cmake hooks
<clever> Infinisil: nix-shell already sources setup for you
<clever> Infinisil: try doing "cd src" inside the preConfigure hook?
<clever> jbaum98: https://github.com/NixOS/nixpkgs/pull/26608 may be of use
<clever> disasm: it should be in the env by default