2019-11-20

<clever> tobim[m]: `-j2` can limit how many things nix builds at once
<clever> darthdeus: heading off to bed now
<clever> tobim[m]: so the directory must exist before it can run mkdir
<clever> tobim[m]: the problem is that systemd obeys line 47, when launching line 35
<clever> tobim[m]: also, try using a multi-line string in systemd.services.<name>.preStart instead of ExecStartPre, then try doing `pwd` and `ls -l /var/log/zeek` from that multi-line string
<clever> tobim[m]: line 47, you must quote that directory, or it wont work right
<clever> tobim[m]: can you pastebin your nixos module?
<clever> tobim[m]: systemd itself is in /nix/store, so thats imposible
<clever> Dandellion[m]: your message is unreadable! 2019-11-20 05:19:02 * Dandellion[m] sent a long message: < >
<clever> tobim[m]: the WorkingDirectory= may apply to the `ExecStartPre` also, i typically just make that dir the home of a user, and set createHome=true;
<clever> in my example, its meant to be ran inside a nix-shell (line 4 reads the var that nix sets)
<clever> darthdeus: the python could then pass those args on you ycm, which then passes it on to a gcc/clang (not sure what it uses internally)
<clever> nix-shell -p ncurses --run 'echo $NIX_CFLAGS_COMPILE'
<clever> -isystem /nix/store/f47fd2c71gbrjs7bikxh65ixkjw8k0hi-ncurses-6.1-20190112-dev/include -isystem /nix/store/f47fd2c71gbrjs7bikxh65ixkjw8k0hi-ncurses-6.1-20190112-dev/include
<clever> darthdeus: in theory, such a script could run:
<clever> darthdeus: i use youcompleteme, and recently read thru its docs, you can write a config script like this in the root of your repo: https://gist.github.com/cleverca22/06b388c1ddd24e88c179f691b36a5590
<clever> Ariakenom: yeah, that is confusing
<clever> Ariakenom: ah, that may have been GC'd already
<clever> Ariakenom: take that path to qtbase, and run `nix-store --query --deriver`, then take the new .drv path and run it thru `nix-store --query --binding src`
<clever> Ariakenom: was it fixed in 5.12 or a patch added after 5.12 was released?
<clever> darthdeus: i host some small sites, but not much big stuff
<clever> ive seen images on reddit take 30 seconds to load
<clever> and sometimes, the browser cant even keep up
<clever> the funny thing, is that most websites cant keep up with me
<clever> its still fun watching the dial on speedtest.net just instantly slam into the peg at the end, lol
<clever> darthdeus: which is much more in line with the "slowest" plan the ISP offers, lol
<clever> darthdeus: i'm pretty sure my 253/582 speedtest was a random fluke, today i get 335/395: https://www.speedtest.net/result/8779256731
<clever> Ariakenom: find a binary within kde, and run `nix-store -qR` on that binary
<clever> Dandellion[m]: you need to do something like: NIX_CFLAGS_COMPILE = "-I${bullet.dev}/include/bullet";
<clever> Dandellion[m]: the issue, is that nix is only adding the include/ dir to the -I paths, so every package that tries to prevent the same issues nix solves (by using include/bullet) breaks nix
<clever> darthdeus: i cant remember how much the bill is, but... https://aliant.bell.ca/Bell_Internet/Internet_access has the plans
<clever> darthdeus: fiber to the home
<clever> darthdeus: i have no idea why it was so backwards that time i measured
<clever> darthdeus: the down is usually faster, and the up is usually slower
<clever> Yaniel: the original statement made no sense at all, but turned out to be exactly right
<clever> Yaniel: oh yeah, that was a fun story
<clever> but its still enough to keep up with https://www.speedtest.net/result/8770046758 my insane internet
<clever> its something like a decade out of date
<clever> so i just grabbed the nearest unused box, and turned it into a router
<clever> it has a memory leak, and 29.5 days of asking it "how many bytes now?" will murder it :P
<clever> and it only started after i began graphing things
<clever> it always failed, 29.5 days after i last reset it
<clever> 6 months of reseting the router, and i realized a pattern
<clever> 29.5 days later, the router just stopped responding, all internet went down
<clever> the real problem, is that i had configured a system to record those numbers, and graph the rate of increase
<clever> and knowing my powers of 2, it just made sense
<clever> and if i moved ~2gig worth of traffic, it reset back to 0
<clever> then it just stopped counting
<clever> i recorded the numbers, it counted normally between 0 and 2147483648 bytes
<clever> its more that the counter just stops counting, 50% of the time
<clever> darthdeus: guess whats worse then that?
<clever> then returns back to 0, lol
<clever> so, the html ui, counts traffic normally from 0 to 2gig, then just stops counting, until another 2gig have passed
<clever> and after the kernel counter overflows at 4gig, the counter wraps back to 0
<clever> the html frontend, then parses that into a 32bit SIGNED int, causing it to cap out at 2gig
<clever> the kernel in the router has regular 32bit unsigned traffic counters, after 4gig it overflows back to 0
<clever> the "router" my isp provided didnt have enough config options, and the byte counters where crap
<clever> it also does other things, like run a full hydra, and an nginx with reverse proxies to split port 80/443 up by subdir
<clever> it does do the normal duties of a router, NAT, dhcp (client and daemon), bind (dns cache)
<clever> that is my "router"
<clever> darthdeus: dual socket Intel(R) Xeon(TM) CPU 3.20GHz, 8gig of ecc ram, 80gig sata hdd, 3 gigabit NIC's
<clever> darthdeus: and virtualbox works on nixos, and can run win10 for testing other stuff
<clever> darthdeus: i now run nixos as the main host on: my desktop, my laptop, my nas, and my router!
<clever> darthdeus: https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh is where $stdenv/setup came from
<clever> darthdeus: you could use that as a base for your own stdenv thing, if you really want to try making nix-shell work
<clever> darthdeus: if you want to see the setup that stdenv uses, nix-build '<nixpkgs>' -A stdenv -o stdenv && ls -lh stdenv/setup
<clever> darthdeus: haskell itself came a while after that
<clever> darthdeus: i learned nix first, and then i learned ghc internals, lol
<clever> darthdeus: nix-shell --pure, will just start that script with an empty PATH, so setup is adding to an empty list
<clever> darthdeus: $stdenv/setup will add all of $buildInputs to PATH
<clever> blitzclone_: you may need to comment out those lines in your ssh host config
<clever> darthdeus: so if your thing wants to work with nix-shell (a fun excercise!), you must have a `stdenv = something`, and that something must contain a `$out/setup`, which adds all of $baseInputs to $PATH
<clever> darthdeus: line 428 will just `source $stdenv/setup`, which assumes the derivation has a `stdenv = something;` and that `$stdenv/setup` will put things into PATH
<clever> darthdeus: when you run nix-shell, it uses this code to generate a small shell script, to be ran within nix-shell
<clever> darthdeus: and i find a lot of people stop reading half way, and then try building a house with only the bricks from a foundation, and they havent even figured out where 2x4's and nails are yet
<clever> darthdeus: they start with the internals of nix, that the stdenv is built around
<clever> darthdeus: one min...
<clever> darthdeus: `nix-shell always provides make` also assumes your using the stdenv
<clever> darthdeus: nix-shell assumes your using stdenv.mkDerivation, and the stdenv provides make/gcc
<clever> darthdeus: it only works with nix-build
<clever> darthdeus: thats not using the stdenv or buildInputs, so that will just completely break everything nix-shell does
<clever> darthdeus: then what is the contents of something.nix ?
<clever> darthdeus: what are the exact args you ran nix-shell with?
<clever> darthdeus: what are the contents of shell.nix?
<clever> darthdeus: and what does `type make` say?
<clever> darthdeus: what does the prompt say when you run nix-shell?
<clever> darthdeus: nix-shell always provides make
<clever> Dandellion[m]: try adding pkgconfig to nativeBuildInputs
<clever> > "${toString 42}"
<clever> Ariakenom: i tend to just run passwd, then steal a line from /etc/shadow
<clever> ,locate bin glxgears
<clever> does lspci detect it?
<clever> lovesegfault: if you get it directly from pkgs.linuxPackages, you risk getting modules for another kernel
<clever> lovesegfault: you must fetch the modules from config.boot.kernelPackages
<clever> kandinski: ls -l /run/booted-system and compare to ls -l /nix/var/nix/profiles/
<clever> make sure no secrets are in the history
<clever> dont forget to go over the `git log`
<clever> your welcome
<clever> lovesegfault: yeah
<clever> jackdk: yeah, it wont accept a revision easily
<clever> 192 in self.callCabal2nix pkg (pkgs.fetchzip {
<clever> 193 url = "mirror://hackage/${pkgver}/${pkgver}.tar.gz";
<clever> pkgs/development/haskell-modules/make-package-set.nix: callHackageDirect = {pkg, ver, sha256}:
<clever> so that {} isnt the right place
<clever> jackdk: yeah, i think the issue is that they are args to haskellPackages.mkDerivation
<clever> jackdk: ah, i guess overrideCabal is the cleanest way it can be done
<clever> jackdk: the revision goes into the 2nd {}, on line 7
<clever> it might have changed after the comment was made
<clever> i was mis-remembering the args for callHackageDirect
<clever> oh
<clever> jackdk: all of that magic is in pkgs/development/haskell-modules/generic-builder.nix
<clever> jackdk: so you want foo = self.callHackageDirect "foo" "1.2.3" { revision = "42"; editedCabalFile = "hash"; }
<clever> jackdk: and editedCabalFile must also be a string, containing the sha256 of the cabal file
<clever> 124 sha256 = editedCabalFile;
<clever> jackdk: it will generate a url like this, based on the revision (which must be a string)
<clever> 121 newCabalFileUrl = "mirror://hackage/${pname}-${version}/revision/${revision}.cabal";
<clever> jackdk: the {} at the end of callHackageDirect can accept 2 arguments, editedCabalFile, and revison
<clever> 14 , version, revision ? null
<clever> 27 , editedCabalFile ? null
<clever> ornxka: read the source to see how you should disable tests
<clever> ornxka: thats a temp dir that nix creates, and will clean up when the build is done
<clever> ornxka: i would set HOME=$NIX_BUILD_TOP

2019-11-19

<clever> nomeata: export IN_NIX_SHELL=impure
<clever> nomeata: that can cause default.nix files to behave differently, which is why i avoid using that
<clever> nomeata: nix-shell sets an env var, and lib.inNixShell uses that env var to detect nix-shell
<clever> raboof: yep, thats the only real difference between checkInputs and buildInputs, it only includes the checkInputs if doCheck == true
<clever> fresheyeball: what does?
<clever> niso: turning the sandbox off will fix NIX_BUILD_TOP
<clever> niso: causing it to fall back to defaults, and trying to unpackPhase when it has no $src
<clever> niso: thats also due to $NIX_BUILD_TOP being wrong, so the buildCommand in runCommand is missing
<clever> niso: nix will keep it, and you can use `nix-store --query --deriver` and then `nix-store --query --binding src` to go backwards from a built dir to its source
<clever> exarkun: fixed in nix master, not sure if its in a channel yet
<clever> heath: you need to turn the sandbox off until your nix is upgraded
<clever> fresheyeball: one weird thing with bluetooth, is that its heavily hardware driven, the bluetooth dongle must support the protocols you want to use
<clever> it might be that your bluetooth card doesnt support a mic
<clever> fresheyeball: did it work before?
<clever> fresheyeball: on the configuration tab
<clever> fresheyeball: in the last tab of pavucontrol, what profile is the bluetooth set to?
<clever> noonien: youll need to check error logs to see what, i think it started with an A
<clever> noonien: i think its something within dbus and gnome, that is crashing when a related service restarts
<clever> the eval-time fetchers (fetchTarball, fetchGit) dont require a sha256
<clever> with a sha256, it has the chance to use a binary cache
<clever> id also recomend using a sha256 with builtins.fetchTarball
<clever> eacameron: builtins.fetchTarball can bootstrap without <nixpkgs>
<clever> eacameron: then every developer is testing with a different version of deps
<clever> eacameron: oh, and for any kind of shared project, you shouldnt rely on the host $NIX_PATH
<clever> eacameron: if you only want a different version of nix, then you just want nix run nixpkgs.nix
<clever> niso: the 2nd shell usually unsets things the 1st shell set, so the 1st shell stops working right
<clever> eacameron: and there is no point in running nix-build in nix-shell
<clever> eacameron: you usually dont want to nest nix-shells
<clever> aranea: that sounds normal
<clever> aranea: was it mounted when you ran nixos-generate-config --root /mnt/ ?
<clever> simpson: when you configured slim for auto-login, it was on a timeout, so you could still interupt it and login as somebody else
<clever> dtz: dang, i was just testing a fix!
<clever> > lib.optionals false [ 1 2 3 ]
<clever> > lib.optionals true [ 1 2 3 ]
<clever> > lib.optional false 42
<clever> > lib.optional true 42
<clever> thats the whole point of startx
<clever> fresheyeball: what does `sudo nix-channel --list` report?
<clever> i need to find a replacement now
<clever> fresheyeball: ive never used the startx mode, i just use slim and login normally
<clever> fresheyeball: you probably just need to reboot after upgrading, some things dont switch right
<clever> gchristensen: both slim and plex-media-player no longer work on master
<clever> fresheyeball: do you have services.blueman.enable = true; ?
<clever> fresheyeball: one min
<clever> Shoubit: services.blueman.enable = true; is required to make blueman work now
<clever> aranea: its under security.wrappers in the nixos options
<clever> aranea: nix doesnt allow any setuid binaries, nixos must generate them outside /nix/store on bootup
<clever> partitionTableType = "none"; would fail the way i was thinking
<clever> lordcirth__: ah, if the default is legacy, then it should accept grub just fine
<clever> lordcirth__: if partitioned = false; then grub may fail to install to the disk, causing some trouble booting
<clever> lordcirth__: to select the result of make-disk-image
<clever> lordcirth__: for example.nix, you need to add -A config.system.build.example
<clever> wedens[m]: but some parts of the config wont be pre-built, like uuid's, and it will need to build a small amount of things after booting
<clever> wedens[m]: you can also eval: import <nixpkgs/nixos> { configuration = ./other-configuration.nix; } and then add it to system.extraDependencies
<clever> wedens[m]: not currently, the iso will need internet access to complete the install
<clever> and then configuration.nix should have imports = [ ./nix-tests/kexec/justdoit.nix ]; kexec.justdoit.rootDevice = "/dev/something";
<clever> wedens[m]: in this case, you want to do: nix-build '<nixpkgs/nixos/release.nix>' -A something-graphical-iso.x86_64-linux --arg configuration ./configuration.nix
<clever> wedens[m]: and that module can be used to freely modify the iso image
<clever> wedens[m]: the configuration arg to release.nix, will add a nixos module to all of the ISO's its generating
<clever> wedens[m]: justdoit.nix will use target-config.nix when installing, so thats where you put your own config
<clever> wedens[m]: you can still boot the iso like a normal nixos installer, and ignore the script if you want
<clever> wedens[m]: yeah, all justdoit.nix does is add a single bash script to $PATH, called justdoit
<clever> rootDevice*
<clever> wedens[m]: the main one youll need to change is kexec.justdoit.device = "/dev/sda"; or nvme0n1
<clever> then use --arg configuration on nixos/release.nix to add it to an iso
<clever> wedens[m]: you then want a configuration.nix file, that sets the nixos options defined in justdoit.nix, and imports it
<clever> wedens[m]: that generates a bash script that will format a device and install nixos in a single command
<clever> wedens[m]: have a look at my justdoit.nix
<clever> ChengCat: the issue, is that the --show-trace is the path that the lazyness was being forced out of things, not the path a value took to wind up somewhere
<clever> ChengCat: but does it mention nixos options at any point?
<clever> ChengCat: --show-trace may give a hint, but the trace is in a wonky direction and can be misleading
<clever> ChengCat: that typically happens if you call mkDerivation and dont pass it a name
<clever> das-g[m]: i would just ignore release-19.09, it wont be getting version updates
<clever> on line 14
<clever> das-g[m]: .text = "${pipenvEnv.drvPath} ${pkgs.pipenv}"; maybe?
<clever> das-g[m]: set `buildCommand = "touch $out";` and it wont need a src
<clever> in the definition for machine
<clever> yeah
<clever> and then the guest will know about the drv
<clever> that will create a /etc/anything in the qemu guest
<clever> das-g[m]: within the nixos config for the guest, environment.etc."/anything".text = pipEnv.drvPath;
<clever> das-g[m]: try adding the .drvPath to any file under /etc/ within the guest nixos
<clever> das-g[m]: i think the issue is that the drv isnt in the guest, only the host (where the test script runs)
<clever> das-g[m]: then try going back to nix-shell -p with a nixpkgs in -I nixpkgs=${..path}
<clever> das-g[m]: oh, but you can use --option substituters "", to disable downloading from the cache entirely
<clever> so testing nix-shell in such a build is difficult
<clever> das-g[m]: the problem is more that your not allowed to use nix inside nix builds
<clever> das-g[m]: not sure then
<clever> t
<clever> only using nix-shell on i
<clever> your not supposed to be building the derivation either way
<clever> das-g[m]: just `let pkgs = import ../../..{};`
<clever> das-g[m]: thats importing pkgs
<clever> machine.succeed("echo ${(import ../../..{}).pipenv}")
<clever> das-g[m]: mkShell just calls mkDerivation for you, and sets the name to something like shell
<clever> yeah, in a let block
<clever> 2019-11-18 21:27:03 < clever> instead, create a derivation that has pipenv in the buildInputs, and then use the .drvPath of that derivation
<clever> das-g[m]: that creates a shell suitable for building pipenv, not using pipenv
<clever> instead, create a derivation that has pipenv in the buildInputs, and then use the .drvPath of that derivation
<clever> it would also be simpler to not use -p
<clever> das-g[m]: if you use nix-shell -p, it will generate a derivation that depends on pipenv and bashinteractive, and try to download it
<clever> yeah
<clever> getting nix-shell working would be nicer, but is obviously more complex
<clever> das-g[m]: i think you want to investigate what was special about nix-shell that broke things, and set those env vars, without nix-shell
<clever> but then pip will depend on nix to build
<clever> das-g[m]: i would probably just use the checkPhase of the pipenv package itself, rather then having its own derivation
<clever> the nixos tests, are just a giant wrapper, to automatically run qemu inside a runCommand i believe
<clever> nix will run that shell code, with the given inputs, and the script must both create $out and exit with code 0
<clever> das-g[m]: pkgs.runCommand "name" { buildInputs = [ pipenv ]; } "shell code here"
<clever> das-g[m]: the test is still ran in the nix sandbox, so nix cleans up anyways
<clever> das-g[m]: that probably doesnt need a nixos test, it could be tested purely from pkgs.runCommand, but simulating nix-shell is the harder part
<clever> das-g[m]: and do you really even need nix-shell, what are you trying to test?
<clever> das-g[m]: but you want to pass it a drv file, that has pipenv in its buildInputs
<clever> das-g[m]: passing a .drv file to nix-shell replaces the need for -p
<clever> yeah, thats why i said to use .drvPath
<clever> probably
<clever> dont remember why
<clever> nilsirl[m]: hydra doesnt build the version with the extension pack
<clever> nilsirl[m]: thats why
<clever> nilsirl[m]: what virtualbox options did you enable?
<clever> nilsirl[m]: did you enable something like guest additions?
<clever> das-g[m]: add `echo ${(import ../../.. {}).pipenv}` to the test script, so it builds it into the sandbox
<clever> das-g[m]: ${./foo} will copy foo into the nix store, and return the path to the copy
<clever> das-g[m]: -I nixpkgs=${./path-to-nixpkgs} ?

2019-11-18

<clever> das-g[m]: the expr you want to nix-shell into
<clever> das-g[m]: in the script where your running nix-shell
<clever> then it will eval it before booting the test, and use the host nixpkgs
<clever> das-g[m]: what if you nix-shell ${(import ./shell.nix).drvPath} ?
<clever> eacameron: nixos is its own function, in nixpkgs/nixos/default.nix, that normally imports its own nixpkgs, based on the config in configuration.nix
<clever> then it will ignore nixpkgs.config and nixpkgs.overlays
<clever> which you can just set to an entire pkgs set
<clever> there is also the nixpkgs.pkgs option
<clever> eacameron: yes
<clever> eacameron: can you paste a more complete example?
<clever> eacameron: what error does it give when you do that?
<clever> eacameron: configuration itself, contains a nixpkgs.overlays option
<clever> ah
<clever> sondr3: i think he has a bot to do it
<clever> 2019-11-18 17:44:17 -!- aszlig [~aszlig@orz.headcounter.org] has joined #bottest
<clever> 2019-11-18 17:44:21 < aszlig> aszlig++
<clever> yeah
<clever> sondr3: if you try to upvote yourself, you loose points
<clever> sondr3: if a directory is in the way, it will put a symlink inside the dir, rather then replacing it
<clever> what does it output?
<clever> what does it output?
<clever> sondr3: what if you manually run `ln -svf /etc/nixos/config/home/emacs/ ~/.emacs.d` ?
<clever> nope, not sure where that went to
<clever> maybe the old apache config...
<clever> gchristensen: ack, my example isnt wsgi anymore, its just plain cgi, lol
<clever> cgi.assign = ( ".py" => "/usr/bin/python"
<clever> gchristensen: is that python?
<clever> sondr3: ~/.emacs.d/ says to create a symlink in an existing directory by that name
<clever> sondr3: drop the / at the end then
<clever> sondr3: is ~/.emacs.d supposed to be a dir or symlink?
<clever> bbl
<clever> then you need tools like yarn2nix, that understand the package manager, and can generate an expr to pre-download things
<clever> with the sandbox on, it will at least fail if i miss something
<clever> chloekek_: but i still have the issue of knowing what it wants in the cache
<clever> chloekek_: for maven/gradle, i replicate the cache directory, and tell it to not touch the network, so it thinks its acting on an old ~/.gradle/caches/
<clever> chloekek_: https would like to ruin your day
<clever> blame apple for making things complicated!
<clever> no idea then
<clever> heath: the link says 8.2
<clever> heath: and it must be the exact version nixpkgs is asking for
<clever> heath: line 50, you must download xcode yourself
<clever> virus_dave: pkgs.substituteAll will take its own vars (which are part of the set you give it), and replace the @var@'s in the file you point it to
<clever> virus_dave: check nixpkgs for uses of that, and you should find some examples
<clever> > pkgs.substituteAll
<clever> > pkgs.substituteInPlace
<clever> evanjs: you can also use nix repl, and then it can cache the results over many options
<clever> evanjs: nixos-option is just a shell script that runs nix-instantiate several times
<clever> aranea: probably simplest to just use the curl script