2017-06-24
01:29
<
clever >
-n, --line-number
01:28
<
clever >
grep can also do that
01:28
<
clever >
which is enabled on most distros, via an alias, but not on nixos
01:27
<
clever >
grep also has --color
00:15
<
clever >
"function wrapProgram" only found <function>wrapProgram
00:10
<
clever >
yeah, but the only documentation is the source
00:09
<
clever >
and neither can search.nix.gsc.io, odd
00:08
<
clever >
it cant find the definition of wrapProgram
00:07
<
clever >
and once again, github search fails
2017-06-23
22:55
<
clever >
and then its imposible to upgrade
22:55
<
clever >
and even then, you must ensure zero references to ghc at runtime, or the 2nd nixos wont fit
22:54
<
clever >
Infinisil: so it would have to be a nixops target
22:54
<
clever >
remote build slaves wont do, since nix wants to download the deps to the local box, then push it out to slaves
22:52
<
clever >
a single copy of ghc would consume over 25% of the disk space
22:51
<
clever >
i had to disable Xorg and fully GC it, before it could finish a nixos-rebuild
22:51
<
clever >
i have a netbook with nixos that barely has enough room for 2 generations of nixos
22:51
<
clever >
but not everyone can afford to waste space like that, lol
22:51
<
clever >
Infinisil: and i think i have 7 copies of ghc 8 on mine
22:49
<
clever >
gcc and c/c++ would be cheaper, but then you run the risk of segfaults
22:48
<
clever >
Infinisil: only cost is the 1gig you need just to install ghc
22:43
<
clever >
and if i do it too fast on windows with putty, it misses keystrokes
22:43
<
clever >
i often hammer out complex sequences of control codes in screen, using ctrl and shift
22:43
<
clever >
oh yeah, and windows cant even keep up with my typing speed, lol
22:42
<
clever >
i suspect it was forcing a vsync between every line of text, or possibly every character
22:41
<
clever >
because of that, xterm framerates where horid, "ls -ltrh" took minutes to output
22:41
<
clever >
so nixos kept using the outdated repo, that had been long forgotten
22:41
<
clever >
but the auto-generated stuff in xorg packages, just got an http dir listing, and built everything in it
22:41
<
clever >
one of the components in the mesa pathway, was merged into another project
22:40
<
clever >
i also discovered some unique nixos problems with the open-source drivers before
22:39
<
clever >
and xfce restores dual-monitor upon login, crashing xorg hard
22:39
<
clever >
the closed-source driver is worse, any attempt to turn on dual-monito crashes xorg hard
22:38
<
clever >
so i must be very carefull near the video cables
22:38
<
clever >
and X also likes to auto-activate any monitor i hot-plug
22:37
<
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
22:37
<
clever >
376 videoDrivers = [ "ati" ];
22:37
<
clever >
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XTX [Radeon R7 260X/360]
22:36
<
clever >
and junk from a previous reboot was in there
22:36
<
clever >
because it rendered the buffer before xfce had loaded the image
22:36
<
clever >
but another strong piece of evidence, the WINDOWS wallpaper was visible on the XFCE desktop after a reboot
22:35
<
clever >
yeah, the lines are blurred a bit
22:35
<
clever >
Ralith: because it happens to every app with tooltips
22:32
<
clever >
but that site doesnt make it possible to just hide a tooltip, it constantly changes it as you move the mouse
22:32
<
clever >
no compositor
22:32
<
clever >
i have to hide, and then re-show the tooltip
22:32
<
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
22:32
<
clever >
sphalerite: the tooltips on that site are nearly unusable due to bugs in my gpu driver!
22:15
<
clever >
ah, sounds different then
22:14
<
clever >
the gpu process alone is using 1.3gig
22:14
<
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
22:13
<
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
22:12
<
clever >
chrishill: and are you installing chromium?, nix-env -iA nixos.chromium
22:07
<
clever >
you have to call the function with arguments before you can access the packages within
22:06
<
clever >
nixpkgs = import <nixpkgs> wont work, because that returns the function at the top of nixpkgs
22:06
<
clever >
justanotheruser: you have to load nixpkgs with either nix-repl '<nixpkgs>' or by running :l <nixpkgs> in nix-repl
22:06
<
clever >
chrishill: you need to set chromium.enableWideVine = true; in your nixpkgs config
22:05
<
clever >
justanotheruser: with what command exactly?
22:04
<
clever >
what did you do to set nixpkgs?, it doesnt exist by default
22:04
<
clever >
this works for me
22:04
<
clever >
nix-repl> builtins.attrNames nix-zsh-completions
20:18
<
clever >
*doh*, i have super and self backwards in my example
20:17
<
clever >
simendsjo: haskellPackages = haskellPackages.override (super: self: { ghc-syb-utils = pkgs.haskell.lib.overrideCabal super.ghc-syb-utils (drv: { doCheck = false; }); }); i think
20:16
<
clever >
simendsjo: there is also haskellPackages.override which handles internal references to ghc-syb-utils for you
20:15
<
clever >
simendsjo: which overwrites the entire haskellPackages set, with a new one containing just a single attribute
20:15
<
clever >
simendsjo: haskellPackages.ghc-syb-utils = doesnt work in an obvious way, it does haskellPackages = { ghc-syb-utils = ...; };
20:09
<
clever >
and i wouldnt really use a blockchain as a replacement for ntp, the resolution is far lower
20:08
<
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
20:07
<
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
20:06
<
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
20:03
<
clever >
MichaelRaskin: you would need to partition the entire internet nearly 50/50 by hashing power
20:03
<
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
03:01
<
clever >
this will pass it python3, under the attribute name python2
03:01
<
clever >
ison111: mod_wsgi.override { python2 = python3; };
02:57
<
clever >
see the above link
02:57
<
clever >
so you need to configure apache, so it configures mod_wsgi correctly
02:57
<
clever >
but its failing at runtime, not build time
02:55
<
clever >
i have a feeling that you need to instead modify the pythonpath within apache
02:54
<
clever >
ison111: what are you expecting it to do?
02:54
<
clever >
but, will adding pillow to the buildInputs actually affect the build?
02:54
<
clever >
ah, that looks like it should have worked
02:50
<
clever >
ah, can you gist the contents of configuration.nix?
02:48
<
clever >
what command did you run?
02:48
<
clever >
ison111: how did you try building the package?
02:28
<
clever >
isnt that flexible
02:28
<
clever >
you have to run the same version on both ends
02:27
<
clever >
some of my servers only have one or the other, and many of them rename the binary to remove the ver number
02:26
<
clever >
main issue ive run into, is v2 vs v3
02:23
<
clever >
this is an example i had throw together many months ago
02:23
<
clever >
justanotheruser: you would need a seperate derivation for every step, and then link them all up in nix
02:22
<
clever >
Infinisil: ah, networking.extraHosts is the cheap way
02:20
<
clever >
Infinisil: services.bind.enable = true; is all you need, lol
02:19
<
clever >
causing things to just fail in wonky ways, because it had no v6 addr
02:18
<
clever >
and have set it up for somebody else recently, their router was returning ipv6 results for an ipv4 query
02:18
<
clever >
i run my own recursive caching server, on nixos
02:16
<
clever >
Infinisil: oh, maybe thats why ive been seeing weird dns issues on this end
02:10
<
clever >
gcc will just set the right headers from the start
02:09
<
clever >
so you have to set LD_LIBRARY_PATH when running it
02:09
<
clever >
justanotheruser: for both python, and java, you cant patchelf the RPATH of the elf file, because its an input, not your output
02:09
<
clever >
justanotheruser: because python is strange
02:03
<
clever >
justanotheruser: you need to wrap the shell script that runs python3 on the python file
02:00
<
clever >
justanotheruser: you need to add the ${freetype}/lib/ to LD_LIBRARY_PATH
01:59
<
clever >
justanotheruser: nope
01:59
<
clever >
ison111: did you use overrideDerivation or overrideAttrs?
01:58
<
clever >
ison111: which override method did you use?
01:57
<
clever >
or it will never use it
01:57
<
clever >
you have to pass it into the panda3d derivation somehow
01:57
<
clever >
how did you pass it to panda3d?
01:57
<
clever >
where did you specify freetype?
01:56
<
clever >
justanotheruser: did you install freetype with nix-env?
01:32
<
clever >
jbaum98: and also, configuration.nix itself is a nixos module
01:32
<
clever >
jbaum98: just put it into the imports list of configuration.nix
00:51
<
clever >
a mac guest in a VM would be harder
00:50
<
clever >
then you can build for either platform, while booted into mac
00:50
<
clever >
or flag a linux VM as a linux build slave, so the mac can still do linux builds
00:50
<
clever >
but in your case, you could do it from a linux VM inside the mac
00:49
<
clever >
this will force it to build a darwin version, ignoring the current host
00:49
<
clever >
then you can do nix-build '<nixpkgs>' -A foo --argstr system x86_64-darwin
00:49
<
clever >
the first 2 options
00:48
<
clever >
then configure nix.buildMachines on your nixos box
00:48
<
clever >
ensure nix is in the $PATH on non-interactive shells (try ssh mac "nix-store --help")
00:48
<
clever >
another fun thing to setup, is darwin build slaves
00:47
<
clever >
so you could prevent nix from building the package on arm, or darwin
00:47
<
clever >
which restricts where nix will even try to build it
00:47
<
clever >
and if hydraPlatforms is missing, it defaults to meta.platforms
00:42
<
clever >
then it can be in the main attribute list as foo-unstable, but not pre-built
00:42
<
clever >
and if its an empty list, none
00:42
<
clever >
that controls which platforms hydra will build it for
00:41
<
clever >
you can also just set meta.hydraPlatforms
00:38
<
clever >
but there is no way to make nixpkgs always build from master
00:37
<
clever >
some packages have a foo and a foo-unstable attribute
00:26
<
clever >
if includeGUI then (buildEnv { name = "foo-with-gui"; paths = [ cli gui ]; } else cli
00:26
<
clever >
and that 3rd one could just return the un-modified cli in the false case
00:25
<
clever >
chrome and firefox plugins work in a similiar way
00:25
<
clever >
that operation is fast, so it can be re-built on the end-users machine
00:25
<
clever >
that will conditionaly merge the cli and gui (either outputs, or seperate packages)
00:24
<
clever >
but you could then make a 3rd package, using buildEnv and arguments
00:24
<
clever >
and always remove the pre-existing one
00:24
<
clever >
the tricky thing there, is that nix-env will think one is an upgrade for the other
00:22
<
clever >
that can be done, but would possibly result in having to recompile it, if the binary cache doesnt have both variants
00:20
<
clever >
so it uses up less disk space
00:20
<
clever >
and then it wont depend on things like libX11
00:20
<
clever >
but if you only install foo.out, the gui can be deleted by a GC
00:20
<
clever >
it will only be in path if you install foo.gui and foo.out at the same time
00:18
<
clever >
c: make 2 packages, which it sounds like youve done already
00:18
<
clever >
b: make a single package that builds both, but puts the gui stuff in the $gui output, via outputs = [ "out" "gui" ];
00:17
<
clever >
a: make a single package that just builds both and puts them into $out
00:14
<
clever >
so i just use nix on all of my old gentoo boxes
00:13
<
clever >
ive given up on installing things with emerge on gentoo, its too slow, but i cant always change the os right away
2017-06-22
23:58
<
clever >
slabity_: try adding "${mozillaPkgs}/rust-overlay.nix" to the overlays list
23:57
<
clever >
i dont think the overlay is meant to be ran thru callPackage
23:57
<
clever >
slabity_: mozillaOverlay does not contain an overlay, and it depends on the value of pkgs
23:52
<
clever >
can you gist your config?
23:51
<
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...
23:51
<
clever >
2017-06-22 20:22:06 < clever> slabity_: you may need to use (import <nixpkgs>{config={};}).fetchFromGithub
23:47
<
clever >
i havent used them before, but you can configure a list of overlays somewhere
23:45
<
clever >
or possibly directly to the overlays list
23:45
<
clever >
passed to either callPackage or import, depending on what arguments it needs
23:45
<
clever >
"${mozillaPkgs}/rust-overlay.nix"
23:40
<
clever >
MP2E: so if you can ssh in either direction, you can get the copy to work
23:40
<
clever >
MP2E: there is both --from and --to, to let you switch the direction its moving the package
23:39
<
clever >
simpson: you can probably alter PS1 in the shellHook
23:38
<
clever >
slabity_: try adding --show-trace, and figure out which file is complaining
23:37
<
clever >
what repo did you give to fetch from github?
23:37
<
clever >
slabity_: i dont think callPackage is the right thing to use there
23:29
<
clever >
i just open nix-repl '<nixpkgs>' and tab-complete fetchFrom
23:29
<
clever >
i can never remember which way it goes and used your question as an example
23:28
<
clever >
slabity_: and the H in Hub has to be in caps
23:25
<
clever >
just dontBuild = true;
23:25
<
clever >
Infinisil: oh, and i found a better answer
23:24
<
clever >
Infinisil: set buildPhase=":"; which causes bash to just do nothing for some reason
23:22
<
clever >
slabity_: otherwise, it will have a circular reference, where the value of pkgs depends on the overlays, which depend on pkgs.fetch...
23:22
<
clever >
slabity_: you may need to use (import <nixpkgs>{config={};}).fetchFromGithub
23:20
<
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
23:20
<
clever >
simpson: you can also optionaly add { arg1 ? "defaultval" }: and then use "--argstr arg1 foo" to change it
23:19
<
clever >
simpson: make a shell.nix containing this: with import <nixpkgs>{}; runCommandCC "dummy" { buildInputs = [ foo bar baz ]; } ""
23:14
<
clever >
and will probably also work on linux
23:14
<
clever >
the sed answer looks much cleaner
23:13
<
clever >
ah, didnt think about tail with a +
23:04
<
clever >
all it did was remove support for /lib/alsa-lib/
23:03
<
clever >
did it also put a usage elsewhere?
23:03
<
clever >
the commit that added the patch
23:02
<
clever >
this also gave me an idea
23:00
<
clever >
my /etc/asound.conf has an =, and also a libs
23:00
<
clever >
libs.native = /nix/store/wlnf10p7pcd244qzxlpqdqlgirkcyizj-alsa-plugins-1.1.1/lib/alsa-lib/libasound_module_pcm_pulse.so ;
23:00
<
clever >
pcm_type.pulse {
23:00
<
clever >
what does the config look like?
22:55
<
clever >
enless there are config files that already comtain things like id=open and id=comment
22:54
<
clever >
so libs=/path/to/libs
22:54
<
clever >
i think id, is the thing to the left of the =
22:51
<
clever >
it appears to modify the parsing of an existing config file that alsa-lib already reads
22:50
<
clever >
so we need to see the original source its patching, and find out what that loops over
22:50
<
clever >
it adds a check if the id variable is "libs"
22:49
<
clever >
jbaum98: the patch is already referenced in the alsa-lib build
22:49
<
clever >
pkgs/os-specific/linux/alsa-lib/default.nix: ./alsa-plugin-conf-multilib.patch
22:42
<
clever >
then create a wrapper that merges the chosen plugins, sets the right variables, and then makes the right wrappers/configs
22:42
<
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
22:41
<
clever >
thats a circular reference, nix doesnt allow it, ever
22:40
<
clever >
jbaum98: "${pkgs.hello}/bin/hello"
22:40
<
clever >
jbaum98: if you just want the output of some other derivation, use that derivations value
19:56
<
clever >
sphalerite: toString prevents it from being copied to the store
19:54
<
clever >
but nix wont use the stuff you manually compiled
19:54
<
clever >
CcxWrk: nix-shell will create an env with things setup
19:53
<
clever >
sphalerite: i tend to use this: du --max=0 -hc $(nix-store -qR /run/current-system) | sort -h
18:14
<
clever >
nix-env -f ~/apps/nixpkgs -iA hello
16:58
<
clever >
Gravious: and yeah, GC may have trouble deleting it
16:58
<
clever >
Gravious: the next time you run a command like nix-store --verify, it will get upset and want to fix it
16:57
<
clever >
nix-shell does change PS1 to say its a nix-shell shell
16:56
<
clever >
and insert that derivation into systemPackages
16:56
<
clever >
ambro718: then you need to make a derivation using runCommand, that creates a $out/bin/foo symlink pointing to ${hello}/bin/hello
16:55
<
clever >
Gravious: under nixos, a script on bootup creates setuid wrappers in /run/wrappers/bin
16:55
<
clever >
Gravious: yeah
16:55
<
clever >
ambro718: anything you add to environment.systemPackages will get merged into that
16:54
<
clever >
ambro718: which bin directory?
16:53
<
clever >
Gravious: and setuid stuff requires nixos, it just doesnt work on other distros
16:53
<
clever >
Gravious: nix-env without -A, will search every derivation in every channel
02:09
<
clever >
Infinisil: ah, yeah, nix doesnt like you doing static linking
02:08
<
clever >
and it will put the 2 git repos into the nix-path
02:08
<
clever >
this will clone 2 git repos, then call release.nix in notos, and pass it all 3 inputs as arguments
02:07
<
clever >
here is an example of how the config should look
02:07
<
clever >
catern: is your hydra gui publicly visible?
02:07
<
clever >
it doesnt just give you a set of boxes
02:07
<
clever >
but unlike the gui, you need to know what fields to fill in
02:06
<
clever >
the new method just generates the same config in a json blob, using another nix expression
02:06
<
clever >
you give it the name of a nix file, and which input its in
02:06
<
clever >
the old method, was to configure the jobset within the hydra gui
02:05
<
clever >
i would have expected that one to be excluded from the restricted mode
02:05
<
clever >
thats part of the internals of nix, that every derivation uses
02:05
<
clever >
that error is weird
02:03
<
clever >
what is the exact error?
02:02
<
clever >
catern: look at each of the services in the hydra module
00:42
<
clever >
nixy: boot.kernelPackages = pkgs.linuxPackages_4_9; for example
00:31
<
clever >
that will create a new version of hello, with libfoo in the inputs, then load it as a shell
00:30
<
clever >
nix-shell -E 'with import <nixpkgs> {}; hello.overrideAttrs (old: { buildInputs = old.buildInputs ++ [ libfoo ]; })'
00:30
<
clever >
jbaum98: you need to use -E and overrideAttrs
00:30
<
clever >
jbaum98: -p generates a derivation on the fly, so it cant be used with other derivations
00:28
<
clever >
nixy: journalctl -f -u display-manager
00:27
<
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
00:26
<
clever >
nixpkgs removed the .git
00:26
<
clever >
but git describe wont work
00:26
<
clever >
Infinisil: i think they want you to run this to generate it
00:26
<
clever >
/nix/store/9nv14d8v56m1ycn4dk2bmhbx2cjf6rd8-scyther-v1.1.3-src/src/describe-version.py: fp = open('version.h','w')
00:23
<
clever >
Infinisil: it still fails, but over half of it compiles
00:23
<
clever >
[ 65%] Building C object CMakeFiles/scyther-linux.dir/switches.o
00:23
<
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
00:21
<
clever >
but its not been split up yet, so it needs to use pkgs.pkgsi686Linux
00:21
<
clever >
idealy, you would use callPackage_i686 when loading this file
00:20
<
clever >
Infinisil: scyther also forces the build to 32bit mode
00:20
<
clever >
12 set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -static -m32")
00:19
<
clever >
Infinisil: scyther looks for its junk in the current dir, not the dir of the cmake files
00:19
<
clever >
nix will make a build directory, cd into it, then run cmake ..
00:19
<
clever >
scyther broke a key feature of cmake, out of tree builds
00:19
<
clever >
yep, thats it
00:18
<
clever >
Infinisil: oh, i have a thought
00:16
<
clever >
but that doesnt fix it
00:15
<
clever >
Infinisil: reading the cmake source, if target isnt set, it defaults to the current host
00:08
<
clever >
then you can see everything that bash does
00:08
<
clever >
it may also help to do "set -x" before you configure
00:03
<
clever >
and you may need a postUnpack hook to append a src to it
00:03
<
clever >
after unpackPhase, you need to cd into $sourceRoot
00:01
<
clever >
and it obeys cmakeFlags, so thats a good place to put the -D's for cmake
00:01
<
clever >
or just skip directly to cmakeConfigurePhase, since you know its there
00:01
<
clever >
so you need to test for the variable, and eval it
00:00
<
clever >
but confusingly, the configurePhase function remains
00:00
<
clever >
line 63 sets $configurePhase to cmakeConfigurePhase
00:00
<
clever >
Infinisil: this file will be sourced by $stdenv/setup, and it will mutate the stdenv some
00:00
<
clever >
Infinisil:
2017-06-21
23:59
<
clever >
Infinisil: let me also link the cmake hooks
23:59
<
clever >
Infinisil: nix-shell already sources setup for you
23:23
<
clever >
Infinisil: try doing "cd src" inside the preConfigure hook?
20:54
<
clever >
disasm: it should be in the env by default