2019-03-01

<clever> gchristensen: ah, nice idea
<clever> gchristensen: is the nameserver written in lua?
<clever> freeluv60spropag: ive been using https://dns.he.net/ for free dns, but aws is another service i use often
<clever> i dont know a single thing about forth :P
<clever> bemeurer: ultimately, you can just do a single nix-build command, and it will build the entire emulator, and kernel, then build a bash script to run the emulator on the kernel!
<clever> bemeurer: https://github.com/siraben/zkeme80/blob/master/default.nix is a related thing i did, i helped to build a forth based kernel for the tr-85 calculator, along with building the entire emulator in nix
<clever> bemeurer: haskell-init is the simplest version of that which i have made
<clever> and which flags it uses, depends on args set later in the file
<clever> bemeurer: this generates a bash script, that runs qemu, with various flags, and a kernel+initrd built by nix
<clever> 115 ++ optional (hostCpuTargets != null) "--target-list=${stdenv.lib.concatStringsSep "," hostCpuTargets}"
<clever> bemeurer: qemu_kvm already has that value, so you can just qemu_kvm
<clever> > "${qemu.name} and ${qemu_kvm.name}"
<clever> and if you then edit pkgs/applications/virtualization/qemu/default.nix
<clever> bemeurer: qemu_kvm is a variant, that only targets the host cpu
<clever> changing hostCpuOnly affects the default of hostCpuTargets
<clever> 15141 qemu_kvm = lowPrio (qemu.override { hostCpuOnly = true; });
<clever> it changes the name of the package
<clever> you can also .override qemu_kvm further
<clever> > qemu_kvm.meta.position
<clever> > builtins.unsafeGetAttrPos "qemu_kvm" pkgs
<clever> *looks*
<clever> > qemu-kvm.meta.position
<clever> > qemu.meta.position
<clever> bemeurer: try the qemu-kvm package
<clever> also, that repo is an edit-distance of 1 away from yours!
<clever> so the end-user has a fully working nix setup, without root, and no /nix/ on the target machine!
<clever> bemeurer: it will also generate bash scripts that chroot into ~/.daedalus/, before running the real package
<clever> bemeurer: this generates an ARX executable (bash+tar) that will install a nix closure to ~/.daedalus/nix/store/
<clever> bemeurer: no, this next thing is madness
<clever> when you nix-build that, it will generate a docker image, that you can then pipe into `docker load` i think it was
<clever> bemeurer: what kind of container?
<clever> or `nix-build -A foo` to build just one thing
<clever> bemeurer: so you can run `nix repl default.nix` and then eval them
<clever> bemeurer: that exposes various things, as a set that default.nix returns
<clever> so i need to take that thing, override just the rust inside it, then re-assemble a new thing that has the same structure
<clever> bemeurer: and the rust channel thing returns such a set
<clever> bemeurer: makeRustPlatform needs a special set, containing .rust, .cargo, and some others
<clever> bemeurer: :D
<clever> adamt: nope
<clever> bemeurer: nix.distributedBuilds+nix.buildMachines is basically distcc
<clever> bemeurer: meant to say nix.binaryCaches = lib.mkForce [];
<clever> bemeurer: oh oops, wrong key
<clever> and it will stop using all caches
<clever> bemeurer: just set nix.binaryCachePublicKeys = lib.mkForce []; in your configuration.nix
<clever> bemeurer: you could simply turn off the binary cache, and build the world without the help of hydra.nixos.org!
<clever> why do you want to change your CFLAGS?
<clever> i dont think its really documented, but it should be possible
<clever> with the proper overrides, or changes to nixpkgs, you can
<clever> i was a gentoo user, prior to discovering nixos
<clever> the nix file deals with fetching a linux kernel, compiling the haskel code (with musl, as a fully static binary), and then buildint an initrd with that code as /init
<clever> sure
<clever> bemeurer: https://github.com/cleverca22/nix-tests/tree/master/haskell-init is something "similar" i did about 2 years ago, its basically a linux distro written purely in haskell
<clever> and it already has conflicts! :D
<clever> bemeurer: that look new enough?
<clever> rustc 1.34.0-nightly (02c4c2892 2019-02-26)
<clever> or rather, make one
<clever> bemeurer: i'll move it to a shell.nix
<clever> bemeurer: mostly builds, the main daedalos derivation lacks a src=
<clever> bemeurer: now the cargoSha256 is wrong, thats progress!
<clever> i see it
<clever> bemeurer: rust.override lacks a .src, which is breaking makeRustPlatform
<clever> bemeurer: testing that on this end
<clever> and rustPlatform is made like this
<clever> 7495 rustPlatform = recurseIntoAttrs (makeRustPlatform rust);
<clever> 7494 makeRustPlatform = callPackage ../build-support/rust/make-rust-platform.nix {};
<clever> ok, so rustNightly is just the raw rust package
<clever> «derivation /nix/store/1awszry76ppvgc7l1z2w7d5isgsg9dxw-rust-1.34.0-nightly-2019-02-26-02c4c2892.drv»
<clever> nix-repl> rustNightly
<clever> bemeurer: poke around more in nix repl
<clever> bemeurer: ah, then rustNightly doesnt have a callPackage
<clever> bemeurer: also, have you been to #osdev ?
<clever> bemeurer: what does rustNightly.callPackage do differently?
<clever> bemeurer: something like buildInputs = [ (pkgs.callPackage ./some_dep.nix {}) ]; maybe
<clever> teto: also note, if you leave the sha256 unchanged, nix assumes the output is unchanged, and wont re-run the derivation, no matter how much you change the postFetch
<clever> teto: but otherwise, it appears to be working normally
<clever> teto: your overlay does a `exit 1` so the build fails
<clever> yl[m]: the example from nixos uses a pkgsModule to set nixpkgs.system
<clever> yl[m]: it can also be raw functions
<clever> teto: and what is the error when you try to build with that overlay?
<clever> teto: can you pastebin the show-derivation output?
<clever> teto: so postFetch may need to `cd $out` first
<clever> teto: the body of the fetch command usually outputs directly to $out
<clever> teto: run `nix show-derivation /nix/store/foo.drv` on the drv that fails to build
<clever> yl: behind the scenes, nixos-rebuild is just calling https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/eval-config.nix#L52-L58
<clever> yl: oh, and now that it is using the module framework, you could do: a = lib.mkMerge [ [1] [2] ]; i think
<clever> and imports is recursive, so any module can define more modules to load
<clever> yl: you can also set a default value inside the mkOption block, which will vanish if the config is set anywhere
<clever> yl: nixos is just repeating that pattern, across 100's of files, until you have a full distro
<clever> yl: yep
<clever> yl: example.nix defines a to be an option, that is a list of ints, and then exrp.nix and expr2.nix set a to different things, [1] and [2], default.nix then merges all 3 files together, and looks at config.a
<clever> yl: example done, pushing to github...
<clever> gillmanash: then its in the $out/nix-support/propagated-* of something of something else the python-user-env depends on
<clever> yl: the module system is fairly easy to work with, let me toss together an example...
<clever> gillmanash: nix already tells you the dependency chain, when it prints everything that failed to build, in the order they depend on eachother
<clever> yl: both // and recursiveUpdate will overwrite the list, not merge it, so you would need to either use a custom recursive function, or the module framework
<clever> gillmanash: you can also give it storepaths to finished builds
<clever> gillmanash: it operates on the runtine closure, which is only known after the build is finished
<clever> but it has since been fixed
<clever> ddellacosta: something was updated for a newer ghc, and it broke older ghc's
<clever> ddellacosta: already fixed in nixos-unstable
<clever> yl: it only works if it passed thru the module framework
<clever> file.out 157,040 x /nix/store/8kn3pq1aks4lclicfa56ifgi6frvwxl4-file-5.30/lib/libmagic.so.1.0.0
<clever> nix-locate libmagic
<clever> ,locate libmagic
<clever> python things may break if you use one package from a different channel, so it may help to get the entire set of python things from staging-next
<clever> slightly modified though, because staging-next doesnt have a channel
<clever> ,unstable
<clever> gillmanash: its a fairly common pattern
<clever> so you may want to replace staging-next with the current git rev
<clever> gillmanash: but that will re-fetch the latest staging-next every time you eval the expression
<clever> gillmanash: (import (builtins.fetchTarball "https://github.com/nixos/nixpkgs/archive/staging-next.tar.gz") {}).python.parted
<clever> gillmanash: nix-build -A python.partd https://github.com/nixos/nixpkgs/archive/staging-next.tar.gz
<clever> mizmorYodh: yeah, that would do it, pulseaudio doesnt like running as root
<clever> mizmorYodh: then pulseaudio isnt starting correctly, what happens if you just run `pulseaudio` in a terminal?
<clever> mizmorYodh: more likely your missing drivers, but we should check pavucontrol first
<clever> mizmorYodh: no
<clever> mizmorYodh: pulse audio volume control, the package and binary names are pavucontrol
<clever> mizmorYodh: and the same in pavucontrol, on the output devices tab?
<clever> mizmorYodh: what kind of audio issues?
<clever> on some machines, it will be sudo nix-channel --list
<clever> talqu: the nixos and nixpkgs there, is the name of a channel from nix-channel --list
<clever> ah, hoogle, that complicates things, yeah
<clever> then (import ./. {}).env.overrideDerivation
<clever> depending on what your default.nix wants
<clever> or maybe: (import ./. {}).env
<clever> talqu: just make this shell.nix: (import ./.).env
<clever> talqu: if you already have a default.nix from cabal2nix, you dont need to mess with shellFor at all
<clever> talqu: is your project on github?
<clever> talqu: was that in a shell.nix? how did you run nix-shell?

2019-02-28

<clever> elvishjerricco: you can use overrideAttrs on .env
<clever> elvishjerricco: ^^^
<clever> hyperfekt: just delete your unpackPhase line
<clever> hyperfekt: youve set it to "true", so it will never copy src in
<clever> hyperfekt: unpackPhase is what is responsible for copying src to the current directory
<clever> hyperfekt: can you pastebin your default.nix?
<clever> kiloreux: looks like the basepointer may be corrupt, so the entire stack trace is bork
<clever> kiloreux: pastebin the whole thing
<clever> kiloreux: then run `bt`
<clever> kiloreux: it wont run the command, but just open the dump of the memory from when it previously crashed
<clever> kiloreux: when opening a coredump, you must give gdb the ELF that created the core, and not a script
<clever> i once wrote a defrag tool for lvm
<clever> kiloreux: then do `ulimit -c unlimited`, and open the coredump it makes
<clever> kiloreux: what does gdb say about the backtrace?
<clever> kiloreux: thats what you must use, with patchelf
<clever> 2019-02-27 15:36:13 < clever> --set-interpreter $(cat $NIX_CC/nix-support/dynamic-linker)
<clever> unix:abstract=/tmp/dbus-zfdmBwEn1u,guid=07be639aaea2303e5bd3214b5c1daa7b
<clever> $ echo $DBUS_SESSION_BUS_ADDRESS

2019-02-27

<clever> monotux: nix does a lot of fun things, like giving a function its own return value
<clever> monotux: thats more about how you would fix nixpkgs properly, but you can use the ugly hostname trick while waiting for nixos-unstable to update
<clever> monotux: it would have to be added to the nixos module for ssmtp
<clever> neonfuz__: yeah
<clever> neonfuz__: thats a bug in setup-etc.pl
<clever> pie__: which will make /nix/store/hash-something/foo/bar.txt
<clever> pie__: you want writeTextFile { name = "something"; text = ''....'; destination = "/foo/bar.txt"; }
<clever> pie__: i'm guessing somebody never tested that
<clever> pie__: derivation names cant contain a /
<clever> and then just ${cfg.extraConfig} at the end of the '' for .text
<clever> i would add an extraConfig option to the module
<clever> the module doesnt properly escape the hostname, so you can abuse it to inject more then 1 line!
<clever> '';
<clever> AuthMethod=PLAIN
<clever> monotux: the simplest (and uglyest) fix is config.networking.defaultMailServer.hostName = ''yourhostname
<clever> monotux: the other source is not using default, so it has a higher priority, and overwrites your "default" value
<clever> hyper_ch: yeah, zfs send will save you
<clever> hyper_ch: snapshots alone dont help you when trim just deletes the data a snapshot refers to
<clever> hyper_ch: trim can have weird edgecase bugs, bug luckily zfs has scrub, so you can audit all data to verify its still there
<clever> hyper_ch: thought you where asking for different config, about what i mentioned above
<clever> hyper_ch: oh, yeah, i got the link
<clever> hyper_ch: that boot stuff is from my pre-nixos days, so it wont be of much use
<clever> elvishjerricco: yeah, the entire os, and all user-data, lived in ra,
<clever> gchristensen: but nixos makes it trivial to exclude the "os" from that whole process, and the user-data is much easier to deal with
<clever> gchristensen: and then i would optionally re-compress it and write-to-disk, at shutdown
<clever> gchristensen: ive manually done similar before with gentoo, my entire rootfs was a squashfs, that i would copy to ram on bootup
<clever> gchristensen: i had another crazy idea recently, what if the initrd used `nix copy` to copy the closure of the active generation, to a tmpfs, and then ejected the boot media
<clever> -rw-r--r-- 1 root root 507 Feb 21 01:34 /var/lib/nixos/gid-map
<clever> -rw-r--r-- 1 root root 897 Feb 21 01:34 /var/lib/nixos/uid-map
<clever> hyper_ch: got a link to the nixos module to apply all the patches?
<clever> slack1256: thats usually done with a nixos module that handles it for you, like programs.light.enable
<clever> --set-interpreter $(cat $NIX_CC/nix-support/dynamic-linker)
<clever> samrose: thats what this file is for
<clever> [nix-shell:~]# cat $NIX_CC/nix-support/dynamic-linker
<clever> /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/ld-linux-x86-64.so.2
<clever> pingveno: and moving them to systemPackages ensures they are always updated with vbox
<clever> pingveno: those must be removed (or upgraded) to fix the problem
<clever> pingveno: but if you have any other QT based programs in nix-env, they can break virtualbox
<clever> samrose: nixos doesnt have a /lib or /lib64, so /lib64/ld-linux-x86-64.so.2 doesnt exist
<clever> samrose: `/lib64/ld-linux-x86-64.so.2`, you forgot to --set-interpreter the binary
<clever> pingveno: you need to remove all QT programs from nix-env -q, and then add the ones you want to keep to systemPackages
<clever> pingveno: you have different QT versions mixed within nix-env and systemPackages
<clever> this will "break" nixos-rebuild, so you dont do that by accident
<clever> and if you nixos-rebuild again, it will also undo anything nixops was doing, and restore whatever configuration.nix said to do
<clever> but you could still `nixos-rebuild --rollback` and undo those changes, if you wanted
<clever> yeah, it will fully take over the machine, and just ignore configuration.nix
<clever> nefix: normal nixos options can be used for that
<clever> nefix: ?
<clever> nefix: if using the none backend, then you must do that, https://github.com/cleverca22/nixos-configs/blob/master/deployments/house.nix#L12
<clever> nefix: you can use the imports list to merge several nixos files together into a single machine
<clever> nefix: only one system profile can be active at once
<clever> samueldr: what is the interpreter now, under `file result/bin/holochain`?
<clever> thblt: so you must now add yourself to the video group
<clever> sounds like the new udev rules, will chgrp something in /dev/
<clever> the description of the option has changed
<clever> `and udev rules granting access to members of the "video" group.`
<clever> oh, yeah, master is different
<clever> thblt: and did it finish without errors?
<clever> thblt: when did you last `nixos-rebuild switch` ?
<clever> slabity: the module adds itself to systemPackages
<clever> jomik: and does it still work after a reboot?
<clever> thblt: what does `which light` report?
<clever> jomik: what error does it give?
<clever> slabity: nix-build '<nixpkgs/nixos/release.nix>' -A options should do it
<clever> gchristensen: that would just require grub-install to understand that, and then boot.loader.grub.device = "/dev/sda1"; i think
<clever> gchristensen: page 11, it mentions every vdev has a 3.5mb hole for boot code, that could allow embeding grub stage 1.5 into the zfs device
<clever> bgamari: ah, that would do it
<clever> bgamari: i dont see any --export in there
<clever> bgamari: where is the code that generates the export?
<clever> bgamari: doesnt fail on this end
<clever> bgamari: testing similar commands locally...
<clever> slabity: line 204 makes an olink-db, and 238 makes man pages
<clever> slabity: this takes an optionsList and generates a json of every option: https://github.com/NixOS/nixpkgs/blob/59f6083281e0e481adf9ff1fbbd30165d4e1e897/nixos/doc/manual/default.nix#L238-L252
<clever> bgamari: what does --import say with -vvvv ?
<clever> bgamari: yeah, those are the only files that are technically NAR's
<clever> slabity: one min
<clever> bgamari: the NAR itself lacks the dependency information and the path to extract it to, so extra metadata is needed to properly restore it
<clever> bgamari: which user did you run it as, and what does `nix show-config | grep trusted-users` report?
<clever> bgamari: also, did you run --import as a trusted user?
<clever> bgamari: --export doesnt generate a plain nar, but something else, that contains a list of nar's
<clever> bgamari: i suspect openssl isnt part of the set of packages your importing, and is also missing from /nix/store, yet that set depends on it
<clever> infinee: its a recursive attribute set, so it can refer to its own attributes, like name = "foo-${version}; version = "1.2.3";
<clever> __monty__: they have the execute bit, but it seems that it translates to a permission denied error
<clever> hence, the permission denied (a directory cant be executable)
<clever> samrose: your telling it to "run" a directory as the interpreter!
<clever> samrose: thats not right!
<clever> interpreter /nix/store/5am5rfzdwdw6zm7ccg2kv7i6rzm7j92y-rust-1.33.0-nightly-2019-01-23-19f8958f8
<clever> vaibhavsagar: you could just run docker on the real host, and then expose /var/run/docker.sock to the nixos container?
<clever> samrose: what does `file result/bin/holochain` report?
<clever> samrose: what is the exact error you get when you run that binary?
<clever> samrose: thats a missing library, not a permisison error
<clever> samrose: you need to add zmq to the rpath

2019-02-26

<clever> hyperfekt: correct, nixos-rebuild is calling eval-config.nix before it loads configuration.nix
<clever> hyperfekt: it may be simpler to call <nixpkgs/nixos/lib/eval-config.nix> and pass it a moduleList param, then to disabledModules every single thing
<clever> asymmetric: currentSystem, can break if you are trying to configure a cross-build from darwin->windows, while doing the eval on linux (hydra)
<clever> asymmetric: not really
<clever> > stdenv.isDarwin
<clever> > stdenv.isLinux
<clever> asymmetric: from nix or bash?
<clever> GryphOne: its a text file, not a binary
<clever> eyJhb: is it using this syscall?
<clever> int isatty(int fd);
<clever> eyJhb: strace it?
<clever> petersjt014: its due to a lack of NCG, and bugs in the llvm backend
<clever> petersjt014: i also looked at ghc on arm (aarch64 to be specific), and it fails to build if you specify more then -j1
<clever> therealwaphire[m: sure
<clever> :D
<clever> lol
<clever> therealwaphire[m: i mainly use it with kexec, which lets me build a tarball that can boot nixos on any linux box
<clever> main problem, is that the params like nvme/uefi, are hard-coded into it, so you have to rebuild the image if you change them
<clever> or build a custom livecd image, with justdoit pre-installed
<clever> therealwaphire[m: edit configuration.nix of the livecd, and nixos-rebuild
<clever> therealwaphire[m: and when the installer is built, it will generate a justdoit bash script, that lands in $PATH at runtime
<clever> therealwaphire[m: justdoit.nix is a nixos module, you add it to the imports section of an "installer" configuration.nix, and also set options like kexec.justdoit.nvme = true;
<clever> edef: not-os is another option, just start over from basically nothing
<clever> such an override would prevent nixos from activating them, which also works, lol
<clever> edef: if any pre-existing lvm exist on the disk your trying to nuke
<clever> edef: nixos will also activate all lvm's, so you must `vgchange -a n` or it will fail to delete those partitions
<clever> therealwaphire[m: it sounds related to my justdoit system
<clever> therealwaphire[m: thats not how you spell disk
<clever> elif [[ $(readlink -f "${dlsk}") == "/dev/nvme0n1p2" ]]; then
<clever> therealwaphire[m: `set -x` at the top of your script
<clever> ldlework: after you reboot, yes
<clever> ldlework: thats what i do for most things
<clever> ldlework: https://en.wikipedia.org/wiki/Asus_Eee_PC#Eee_700_series i have a pair of 701's
<clever> in my case, it was an SSD soldered to the motherboard
<clever> ldlework: even worse!, i was working with 4gig, lol
<clever> ldlework: how big is the disk?
<clever> ldlework: ive had that trouble with my netbook's before, had to copy an extremely minimal one over, to get enough free
<clever> alex_giusi_tiri: probably
<clever> libibverbs,librdmacm: remove in favour of rdma-core
<clever> commit 7ce08cb18e6faa244caa0221b0c1e5fb6663ce26
<clever> ,locate libibverbs
<clever> so <nixos> and <nixpkgs> are usually identical