2019-03-07

<clever> srhb: because the VM doesnt specify details like that
<clever> srhb: a common VM issue i have with zfs, there are no symlinks in /dev/disk/by-path
<clever> spikebike: so i just need 4 arrow keys, enter, and escape, to navigate my entire media library
<clever> spikebike: this runs plex full-screen (in tv mode) on my nas, which is plugged into the tv upstairs
<clever> spikebike: one min
<clever> sudo cat /etc/X11/Xsession.d/51gtk3-nocsd-detect
<clever> so when you run any nix based binaries, it looses the ability to search /usr/lib/
<clever> but nix ld.so cant
<clever> i think the problem, is that ubuntu ld.so, can search /usr/lib

2019-03-06

<clever> hyper_ch2: not yet
<clever> avn: yes
<clever> import <nixpkgs> { config = ....; };
<clever> Myrl-saki: would probably be simpler to just set the config argument
<clever> Myrl-saki: probably
<clever> Myrl-saki: note. stdenv.shell is the non-interactive bash, so a lot of features will be missing
<clever> slack1256: and this will show everything, and follow symlinks
<clever> [clever@amd-nixos:~/Downloads]$ find -L /run/current-system/kernel-modules
<clever> slack1256: there is a symlink here, that points to the current modules
<clever> lrwxrwxrwx 13 root root 58 Dec 31 1969 /run/current-system/kernel-modules -> /nix/store/cp9ymg1diqfppadiy2395nl6s48j1pra-kernel-modules
<clever> { pkgs, ... }: let key=value; in { key2 = value2; }
<clever> so you basically want:
<clever> { key = <value>; } is also a value (and an attrset)
<clever> is also a value
<clever> let key = <value>; in <value>
<clever> is a function that takes pkgs, and returns a value
<clever> { pkgs, ... }: <value>
<clever> the let goes before the {
<clever> can you pastebin what you currently have?
<clever> line endings dont really matter at all
<clever> with pkgs; let mediapkgs = [ mpv ]; in { home.packages = mediapkgs ++ thing; }
<clever> you likely want a let block
<clever> thats a normal set, and it cant refer to its own attrs
<clever> 59 could be `with pkgs;` but since 3 now does that, 59 doesnt need a with at all
<clever> tA: and line 59, you are re-importing nixpkgs
<clever> tA: yep, line 3, that will cover the entire file, but it might have other problems now
<clever> can you redo the pastebin, and include lines 1-3?
<clever> you either need the with pkgs; higher up (cant say where, lines 1-3 are misisng), or put a with pkgs; on each thing
<clever> tA: mpv is on line 5, and the list from 4-13 lacks a `with pkgs;`
<clever> and :set nu, to turn them back on
<clever> tA: for future reference, :set nonu
<clever> tA: can you pastebin the actual code you used, and the real error?
<clever> tA: i think its parsing it as (with pkgs; [list1]) ++ [ list2]; and so the with doesnt effect the 2nd list
<clever> tA: try with pkgs; ([list1] ++ [list2]); ?
<clever> tA: that looks like its mostly valid, what is the error code it gives?

2019-03-05

<clever> suzu: you should be able to just do aeson = self.callCabal2nix "aeson" /path/to/custom/aeson {}; for example
<clever> suzu: the packages coming from nixpkgs lack a src=, so they wont be changed
<clever> (the stuff coming from nixpkgs lacks a src=, and will be un-changed)
<clever> and then filterSource the .src of everything that has a src=
<clever> basically, this overlay will replace the mkDerivation used by every haskell package
<clever> suzu: you can also use your nix-gitignore in the above
<clever> so nobody will see the problem, ever again (until cabal and/or ghc adds another problem :P )
<clever> ottidmes: yeah, but once changed, it would fix it for everybody
<clever> the file will still trigger a rebuild when it changes, but its much much simpler to rm inside the build, then to omit it entirely
<clever> another option, is to just dont bother with filtering, just modify generic-builder.nix to delete the file (with rm) before doing a build
<clever> noonien: `which --all python`
<clever> noonien: but if you have 2 pythons propagating, they could conflict
<clever> noonien: you would have access to a variant of python, that has fontforge in the pythonpath
<clever> kk
<clever> infinisil: how did you test things?
<clever> infinisil: that should work
<clever> (well, shouldnt)
<clever> infinisil: and the nix store is immutable, so you cant g+s after the build
<clever> infinisil: and recently, the sandbox has been modified, so you cant even make a binary setuid nixbld1
<clever> infinisil: all nix builds occur as a member of the nixbld group, like nixbld1, so you cant make it setuid root
<clever> infinisil: at the nix level, setuid binaries are not allowed, so nixos creates those setuid wrappers outside the nixstore, on bootup
<clever> infinisil: then you need to recreate the security.wrappers, and have the end-user run it as root to grant the wrapper permissions
<clever> infinisil: this example, makes dumpcap setuid root, and restricts it to members of the wireshark group: https://github.com/cleverca22/nixos-configs/blob/master/wireshark-no-root.nix
<clever> infinisil: you must use security.wrappers (https://nixos.org/nixos/options.html#security.wrappers) to have nixos generate a wrapper at activation time
<clever> infinisil: nix builds are never able to create setuid or setgid binaries
<clever> yeah, thats what it looks like
<clever> Myrl-saki: have you seen the example i recently did?
<clever> andrewrk: that util is less for packing properly, and more for testing things you dont want to package immediately, but yea, it is nix-speciic
<clever> (since nix wont know the ELF is using them)
<clever> as an added benefit, the result pointing to the bash script roots those libraries, so nix cant GC them on you
<clever> andrewrk: if you then run that bash script on an ELF, it will fix the dynamic linker, and rpath
<clever> andrewrk: if you nix-build this file, it generates a bash script
<clever> andrewrk: i have a util that likely does exactly what you want
<clever> andrewrk: one sec
<clever> buildInputs is for the target, native for the host
<clever> the difference only comes into play when your doing cross-compiles
<clever> suzu: no real difference when doing a native nix-shell thing
<clever> suzu: ive read the source for .env and know it only has a ghc with your haskell deps
<clever> andrewrk: inside nix-shell or a nix-build script
<clever> andrewrk: cat $NIX_CC/nix-support/dynamic-linker
<clever> andrewrk: one sec
<clever> suzu: you must override the .env seperately, like you already did with cabal-install
<clever> suzu: normal.env wont include the normal.buildINputs
<clever> suzu: and what did you run nix-shell with? what is shell.nix?
<clever> noonien: and master is checked on every push (i think)
<clever> noonien: nixos-unstable is the latest version of master to pass a set of tests
<clever> suzu: can you gist the nix files you tried?
<clever> Myrl-saki: yeah, those could also be used to optimize it further
<clever> suzu: if you want the binary from nix-build to find the dep, then you want to nix-build the writeScriptBin instead
<clever> if you want to compile and run that hs code in nix-shell, then the dep should be in your regular nativeBuildInputs
<clever> suzu: depends on what your goal is
<clever> so its less of an issue there
<clever> suzu: nix-shell obeys propagatedNativeBuildInputs and will add it to PATH for you
<clever> suzu: that will generate a bash script called foo, that extends PATH, then runs the haskell thing
<clever> suzu: so at build-time, you have to either embed $(which pandoc) into your code somewhere (template-haskell, ew!), or generate a bash script that puts the path into a shell script wrapper
<clever> suzu: runtime deps are detected automatically, based on the subset of build-time paths, that wind up as strings in your output
<clever> noonien: yep
<clever> suzu: correct, it will only be in PATH at build-time
<clever> noonien: ^^^
<clever> commit 09d708eee393f9d95175979a4d59d5a5f3ca96a8
<clever> Author: Tim Steinbach <tim@nequissimus.com>
<clever> Date: Mon Mar 4 07:35:03 2019 -0500
<clever> suzu: but the only sane way to ensure its in PATH, is to wrap it with a bash script that extends PATH
<clever> suzu: you usually want to have another derivation, that makes a bash script, extending PATH, and then running the haskell thing
<clever> suzu: it wont have any effect at normal runtime
<clever> suzu: propagatedNativeBuildInputs only exist at build-time for other things that depend on your thing
<clever> noonien: which user is the channel on? --list
<clever> noonien: also, which user did you --update as?
<clever> nixos is 10 hours old, nixpkgs is 8 hours old
<clever> noonien: when did you last nix-channel --update?
<clever> > linux_latest
<clever> noonien: i tab-complete linux in `nix repl '<nixpkgs>'`
<clever> joko: the pastebin i linked, i think is running the unfinished trim code, from a pr
<clever> ij: i think it was gchristensen that gave it to me
<clever> 2019-03-05 11:44:27 [freenode] -!- clever [~clever@NixOS/user/clever]
<clever> gchristensen: this was a chunk of patches to get a new zfs and trim working in nixos
<clever> 2019-02-27 16:57:56< hyper_ch> clever: I used this https://paste.simplylinux.ch/view/raw/c8b41aad
<clever> suzu: ahh, it was Data.Text, not Data.String
<clever> suzu: https://github.com/input-output-hk/cardano-sl/blob/develop/nix/overlays/required.nix#L36-L39 is the 4 packages i actually had dup'd, and how i fixed them
<clever> Uma_: `systemd-analyze plot` and read the related units in /etc/systemd/system/
<clever> suzu: so that overlay causes haskellPackages.base to be null, and effectively do nothing
<clever> suzu: so the versions cant be changed, and adding the same package via the inputs will only give dups
<clever> suzu: the ghc package has all of those boot packages baked into the same derivation
<clever> then you can manually run fsck
<clever> Uma_: add boot.debug1devices to the kernel cmdline, and it will give you a shell in the initrd
<clever> defaults to true
<clever> so i had to repeat that list within stack2nix to fix it
<clever> but stack2nix undoes that
<clever> suzu: nixpkgs nulls out every boot package, so you cant get duplicates
<clever> `ghc-pkg list` did show 2 of them
<clever> it was still a boot package though (baked into nix's ghc package)
<clever> it was a different type, but i cant remember which one
<clever> dep used 1, shell used a 2nd
<clever> 2 different versions of the same library where in scope
<clever> suzu: i once ran into a type error, expected Data.String, got Data.String
<clever> and if things get out of sync, all qt apps break hard
<clever> QT propagated the libs into ~/.nix-profile if you nix-env things
<clever> that is also what breaks QT
<clever> suzu: thats also why i use cabal-install from the same nixpkgs, rather then just nix-env -i it, like others do
<clever> suzu: yep
<clever> suzu: but if you use a new cabal field in the cabal file, it will keep working in nix-shell, but then later fail in nix-build with the old cabal
<clever> suzu: using a newer cabal can sometimes cause weird problems, where it may work in nix-shell and fail in nix-build
<clever> illegalprime: thats cc-wrapper, a bash script that enforces various things
<clever> tokudan[m]: i had so many tabs open, that that UI was laggy
<clever> suzu: vimium, shift+t to search all open tabs by title
<clever> suzu: regular tabs
<clever> chromium
<clever> currently have 840 tabs open
<clever> i really need to get better at closing my tabs
<clever> suzu: heh, generic-builder, script-runner, and make-package-set where all open in tabs beside eachother, from the last time i demo'd how this works, lol
<clever> suzu: yep
<clever> suzu: callCabal2nix and shellFor should be in the same directory
<clever> if you make a gist with both the default.nix and shell.nix, i can adjust it to share the pinning
<clever> blame haskell people :P
<clever> yeah
<clever> would be simpler if default.nix also did `inherit pkgs;` then you can reuse the pkgs set
<clever> suzu: (import ./default.nix {}).normal.env.overrideAttrs (drv: { buildInputs = drv.buildInputs ++ [ ( (import <nixpkgs>{}).haskellPackages.cabal-install ) ]; })
<clever> suzu: .env is a normal derivation that can accept normal overrides
<clever> one min
<clever> you can, but i just dont bother
<clever> `ghc Setup.hs -o Setup`
<clever> suzu: so you need to compile Setup.hs to get a cabal-like binary
<clever> suzu: nix doesnt provide cabal (the binary) but rather Cabal (the haskell library)
<clever> suzu: yeah, thats what i was going to recomend
<clever> suzu: can you pastebin your current default.nix?
<clever> joko: the initrd is a fairly sensitive area, so you may break things when upstream changes stuff, so maybe just file a PR to nixpkgs
<clever> joko: yep, just need to do it after luks, and ensure luks didnt clean it up
<clever> joko: that is the /init from inside the initrd
<clever> joko: and to aid your debug, do `nix-build '<nixpkgs/nixos>' -A config.system.build.bootStage1` and then read the script result points to
<clever> joko: you might be able to modify things to try the same pw on zfs, but the luks stuff deletes that file when its done, so it could be tricky
<clever> joko: and if 2 luks volumes in a row need the same pw, it will just unlock both with a single prompt
<clever> joko: this code will temporarily save your luks password to a tmpfs at /crypt-ramfs/passphrase
<clever> kai_w: you could just change TMPDIR to /tmp/
<clever> joko: would need some changes to stage-1.sh, one sec
<clever> kai_w: why do you need to use a diff dir?
<clever> yep
<clever> you could also PR things to move them around
<clever> CMCDragonkai: its mostly a choice left to whoever wrote the code first and how its planned to be used
<clever> CMCDragonkai: some of those are used like a replacement to configuration.nix, nix-build '<nixpkgs/nixos>' -I nixos-config=/foo/nixpkgs/nixos/modules/virtualisation/something.nix -A config.system.build.fooImage
<clever> due to xen breaking 9plan, i had to generate a full disk image (including a valid bootloader and MBR)
<clever> CMCDragonkai: https://gist.github.com/cleverca22/010456d1d1895f760bd8244fd62ffd9f#file-insane-nix-L36-L45 is an old example, of how i booted xen inside qemu
<clever> CMCDragonkai: mostly up to the person that wrote things
<clever> nixos/maintainers/scripts/ec2/create-amis.sh is a bash script, that will nix-build amazon-image.nix, and upload the products to aws
<clever> CMCDragonkai: and thats the specific one used for AMI's
<clever> nixos/maintainers/scripts/ec2/amazon-image.nix: config.system.build.amazonImage = import ../../../lib/make-disk-image.nix {
<clever> CMCDragonkai: this will find all examples within nixpkgs
<clever> [clever@amd-nixos:~/apps/nixpkgs]$ grep -r --color make-disk-image.nix
<clever> CMCDragonkai: this is the file you want
<clever> azure-image.nix: system.build.azureImage = import ../../lib/make-disk-image.nix {
<clever> CMCDragonkai: one min
<clever> WilliamHamilton[: tossed a comment in
<clever> Ashy: to get that in a shell, nix-shell -p 'ffmpeg-full.overrideAttrs (drv: { configureFlags = drv.configureFlags ++ [ "--enable-libcaca" ]; })'
<clever> Ashy: is my first guess
<clever> nix-build -E 'with import <nixpkgs> {}; ffmpeg-full.overrideAttrs (drv: { configureFlags = drv.configureFlags ++ [ "--enable-libcaca" ]; })'
<clever> WilliamHamilton[: not sure, definitely sounds like a bug, having a pkgconfig file in z3 might also help, not sure
<clever> WilliamHamilton[: it still needs the right LDFLAGS to find the static libs
<clever> yep
<clever> ghcid is enough to know when i break things
<clever> thats part of why i havent bothered setting up any more IDE like stuff
<clever> and you would have to run emacs inside the nix-shell
<clever> suzu: then `runhaskell Setup.hs && runhaskell Setup.hs build` and maybe `ghcid -c "runhaskell Setup.hs repl"`
<clever> suzu: nix-shell default.nix -A normal.env
<clever> yeah
<clever> i often test with nix-build -A foo && ./result/bin/foo
<clever> suzu: yep
<clever> suzu: rm result-1 result-2
<clever> suzu: when you run nix-build on a set, it creates 2
<clever> suzu: yeah
<clever> but ghci wont obey that!, i think i see the issue
<clever> WilliamHamilton[: cc-wrapper will then forcibly add that, when calling gcc to link things
<clever> WilliamHamilton[: it should be in things like NIX_LDFLAGS
<clever> suzu: add result to the .gitignore
<clever> suzu: if you do src = ./.; then the result symlink will change the source, so every nix-build invalidates the cache by mutating the source
<clever> WilliamHamilton[: what about `env | grep --color z3`
<clever> suzu: nix-shell impurely fetches bash from <nixpkgs>
<clever> nearly all nix commands accept -I
<clever> then it will reuse the nixpkgs nix-shell is already loading
<clever> but you could make it slightly faster, with import ./default.nix { inherit pkgs; }
<clever> to call it with an empty set of args
<clever> suzu: the default.nix returns a function, so you need import ./default.nix {}
<clever> suzu: oh, lol, i was reading the error {^_^} gave, not the one you gave!
<clever> WilliamHamilton[: not sure what else to try there
<clever> WilliamHamilton[: dont think that will help much, its refering to changes in stack.yaml
<clever> then nativeBuildInputs may be best
<clever> suzu: though if your baking its path into something, you can embed the result of $(which foo) at build time
<clever> suzu: buildInputs would mostly be if you want to run it or link against it, at build time
<clever> so when you nix-shell -p hello, its just dropping you into a shell with buildInputs = [ (hello) ];
<clever> suzu: behind the scenes, nix-shell -p is just doing -E, with buildInputs = [ ((import ./default.nix).static) ];
<clever> suzu: yep
<clever> suzu: nix-shell -p '(import ./default.nix).static)' for example
<clever> suzu: yeah
<clever> suzu: you want either -A normal, -A static, or just replace the set with one of those values directly
<clever> suzu: if you give nix-build a set, it will build every attribute on it
<clever> suzu: yay
<clever> WilliamHamilton[: weird, what about `cabal repl` ?
<clever> suzu: can you pastebin both the error and the nix file?
<clever> WilliamHamilton[: what about with just `cabal build`, ignore the new- commands?
<clever> WilliamHamilton[: i'm not sure the .env attribute supports native libraries, you may need to adjust line 34 to do: (drv.env.overrideAttrs (drv: { buildInputs = drv.buildInputs ++ [ pkgs.z3 ]; }))
<clever> i'm not entirely sure why the order matters for that, i would have expected it to work either way
<clever> that will fetch version 1.2.3 of aeson
<clever> or within an overlay, self.callHackage
<clever> haskellPackages.callHackage "aeson" "1.2.3" {}
<clever> you can also use things like callHackage
<clever> then you can pray it still builds
<clever> that will just ignore the version constaints
<clever> suzu: stripe-core = pkgs.haskell.lib.doJailbreak super.stripe-core;
<clever> suzu: then line 15 uses hspkgs when calling cabal2nix, so it obeys that overlay
<clever> suzu: line 13, then calls haskellPackages.override, and passes it the overlay, and stores the new haskell packages in hspkgs
<clever> suzu: line 9-12 defines an overlay function, that modifies bugsnag-haskell
<clever> suzu: line 11 should be disabling it
<clever> suzu: and which package needs to have tests disabled?
<clever> suzu: ah, neat
<clever> can you pastebin your current nix file?
<clever> other tests may be similarly poo
<clever> r
<clever> so the tests arent pure, and will fail under a nix sandbox
<clever> suzu: the datadog tests for example, want a datadog api key, and internet access, to perform a test
<clever> suzu: bugsnag-haskell = pkgs.haskell.lib.dontCheck super.bugsnag-haskell;
<clever> and a PR should probably be filed, after the changes are confirmed
<clever> yeah
<clever> though, if the build is failing, its not in the binary cache anyways
<clever> but, beam-core then wont have any help from the binary cache
<clever> and then it will force it to have zero patches
<clever> similar to how i overrode datadog in extra-statsd, you can do beam-core = pkgs.haskell.lib.overrideCabal super.beam-core (drv: { patches = []; });
<clever> and that patch in nixpkgs is no longer required
<clever> suzu: it looks like beam-core upstream have applied the same patch to their source
<clever> suzu: i did a search on github for beam-core-fix-ghc-8.6.x-build, within the nixpkgs repo
<clever> suzu: can you pastebin the full output from nix-build?

2019-03-04

<clever> suzu: re-run nix-build with -j1
<clever> i think part of it is just freakishly good memory
<clever> and i can tell you what file to find common functions in, for most of those projects
<clever> suzu: i have identifed linux kernel source, just from a random screenshot in a tv show, that used it to represent "hacking"
<clever> suzu: i memorized the source code for linux, nix, nixpkgs, nixos, nixops, android, ghc, the list goes on .....
<clever> noonien: i would say that its a bug in command-not-found
<clever> noonien: i think its now in bind.dnsutils
<clever> suzu: so you can just use that, and then run nix-build
<clever> suzu: callCabal2nix will get the deps the cabal file lists
<clever> suzu: start with a nix file similar to the extra-statsd one