2018-07-19

<clever> hyper_ch: then try running that one and see if it differs
<clever> hyper_ch: run `less /init` and find the command nixos uses to import the pool
<clever> hyper_ch: yeah
<clever> hyper_ch: then you can try to manualy import the pool and see what the problem is
<clever> hyper_ch: if you boot.debug1devices then it will "fail" immediately before importing your pool, and give you a shell
<clever> hyper_ch: nixos will import all pools in the postDeviceCommands: https://github.com/NixOS/nixpkgs/blob/release-18.03/nixos/modules/tasks/filesystems/zfs.nix#L326-L352
<clever> hyper_ch: yeah, but there isnt much information there, you want to get a shell before it imports the pools and try to inspect what is going wrong
<clever> ghostyy: you need to use clangStdenv.mkDerivation
<clever> Guest50547: you can always rollback from grub if it ever breaks massively, and always change the channel back whenever it does break
<clever> Guest50547: i also run nearly all of my machines from nixos-unstable, and they are perfectly stable
<clever> Guest50547: if you check `nix-channel --list`, youll see you have 2 channels on root, `nixos-rebuild` only uses the channed named nixos
<clever> Guest50547: the above change should also work, and entirely ignore channels
<clever> Guest50547: simplest thing is to just change the import <nixpkgs> to: import (builtins.fetchTarball "https://github.com/nixos/nixpkgs/dae9cf6106da19f79a39714f183ed253c62b32c5.tar.gz") {}
<clever> hyper_ch: check the journal and dmesg, and top
<clever> Guest50547: you can also change your nix expressions to always load the unstable directly, and ignore what channel the user has
<clever> hyper_ch: i spoke just 40 seconds ago :P
<clever> Guest50547: add nixos-unstable to roots channel list and then run update again for root
<clever> Henson: this nix expression will generate a tar containing hello
<clever> Henson: nix-repl> :b pkgs.callPackage (pkgs.path + "/nixos/lib/make-system-tarball.nix") { fileName = "tarball"; contents = []; storeContents = [ { object = pkgs.hello; symlink = "hello"; } ]; }
<clever> Henson: run `nix-store -qR` on the path and tar up everything in that list, there is also a nix expression to do it
<clever> Guest50547: you may need to add nixos-unstable to roots `nix-channel` as well
<clever> Guest50547: try changing the `import <nixpkgs>` to `import <nixos-unstable>` and see if that makes any difference
<clever> Guest50547: what nix expression are you currently using?
<clever> Guest50547: its probably defaulting to roots channel, which is pinned to the stable 18.03 channel
<clever> infinisil: correct, the installPhase is responsible for the pre/post hooks
<clever> Guest50547: what does `nix-channel --list` report for each user?
<clever> Guest50547: try with sudo as well, then restart the nix-shell
<clever> Guest50547: when is the last time you did a `nix-channel --update`
<clever> samueldr: or nix run nixpkgs.foo
<clever> _d0t: virtualisation.virtualbox.host.enable = true;
<clever> try putting the trace deeper into things
<clever> nh2: your testing too far out, on the same value that already freezes
<clever> yep
<clever> yet it still works
<clever> infinisil: which is why i re-imported my own copy with it dis-allowed
<clever> > (import <nixpkgs> { config.allowUnfree = false; }).teamviewer.meta.license
<clever> > builtins.tryEval ( (import <nixpkgs> { config.allowUnfree = false; }).teamviewer)
<clever> > pkgs.teamviewer
<clever> > builtins.tryEval pkgs.teamviewer
<clever> tryEval may help though
<clever> i think the problem, is that you cant eval any part of an unfree package, so you cant test if its unfree and filter it out
<clever> before it can give you the first item
<clever> so it has to at least partially evaluate every single value, to fill the list with thunks
<clever> nh2: the length of a list is not lazy
<clever> nh2: it has to know the length of the list first
<clever> because it didnt fail like most other lists would have in nix
<clever> and then you spend an hour trying to figure out why it doesnt work
<clever> yeah, if you miss the () by accident, the function gets filtered out
<clever> and it doesnt fail
<clever> infinisil: the dontCheck is entirely ignored, and has no impact on the storepath
<clever> > "${haskellPackages.ghcWithPackages (ps: [ haskell.lib.dontCheck ps.lens ])} ${haskellPackages.ghcWithPackages (ps: [ ps.lens ])}"
<clever> it will silently filter the function out
<clever> infinisil: so if you pass it [ haskell.lib.dontCheck hsPkgs.foo ];
<clever> infinisil: another fun thing i discovered, the haskell package array you pass to most haskell tooling, filters on isHaskellLibrary
<clever> hodapp: they had to bootstrap this computer from punchcards, lol
<clever> its the only thing that big :P
<clever> dramforever: i can tell your downloading ghc just from the size of the download :P
<clever> irc12286: yeah, id ctrl+c it, then run `nix-collect-garbage --max-freed 1`
<clever> hodapp: cant you just split the python bindings into a seperate derivation?
<clever> vaibhavsagar: ah, looking at the source, the error implies that run() should never return, but it did
<clever> vaibhavsagar: fprintf(stderr,\"What, run() returned!\\n\"); is a line in some of the src
<clever> vaibhavsagar: dang, got distracted
<clever> so the strace is going to capture the run() issue
<clever> vaibhavsagar: nix-build fakes the uname, so it thinks the kernel is 32bit only, when set to 32bit mode
<clever> vaibhavsagar: re-running nix-build with an strace on the nix-daemon
<clever> vaibhavsagar: so the build system is broken and checking uname to see what arch it should target
<clever> vaibhavsagar: nix-build with a sandbox enabled will fake the uname output
<clever> vaibhavsagar: i think i see the problem, nix-shell is giving you a 32bit only gcc, but uname still reports 64bit
<clever> vaibhavsagar: i ran nix-shell then genericBuild, its building again
<clever> vaibhavsagar: i also get that run() error with nix-build
<clever> vaibhavsagar: and how does it behave differently in nix-shell?
<clever> vaibhavsagar: what stage does it fail at?
<clever> vaibhavsagar: yeah, that should give a 32bit shell
<clever> vaibhavsagar: what is the content of default.nix?
<clever> vaibhavsagar: use pkgsi686Linux.stdenv.mkDerivation, not -p
<clever> srk: i always use an ext4 /boot
<clever> hyper_ch2: /nix/store/ is too big for poor old grub to read :P
<clever> hyper_ch2: if /boot and /nix/store are on the same FS, then the default grub.conf file will just direct grub to read /nix/store/ directly
<clever> hyper_ch2: copy kernels to /boot/
<clever> hyper_ch2: allow a shell by editing the kernel params in grub, then try to import it manually, what happens?
<clever> yep
<clever> kalbasit: also, super and self are likely copies of nixpkgs, so you can skip line 4 entirely
<clever> kalbasit: by setting config = {}; you can stop all the overrides from leaking in
<clever> kalbasit: maybe also pass config={}; to line 4 as well
<clever> kalbasit: and once you do import it, pass config = {}; to make it ignore the overrides on the host
<clever> kalbasit: line 8, your not even importing the pinnedPkgs, your trying to treat the path as a set
<clever> kalbasit: you have an override in your ~/.config directory that isnt compatible with the pinned version
<clever> .overrideAttrs
<clever> it will create a $out/nix-support/failed to indicate failure
<clever> fresheyeball: if you set succeedOnFailure on a derivation, then it will still pass, even when failing
<clever> angerman: i usually just let /etc/nix/machines auto-select one at random

2018-07-18

<clever> le_jonge: you need to use the repl command i believe, not project-test
<clever> le_jonge: nix-build will check the value of argv[0] to decide what mode to run in
<clever> le_jonge: nix-shell and nix-build are the exact same binary, both are in the nix repo
<clever> le_jonge: ghc itself is not installed, so i dont need --pure very often
<clever> le_jonge: this is why i just installed ghcid system wide
<clever> le_jonge: you could maybe use mapAttrs in shell.nix, to mutate every single attribute, and do it in a shallow manner, so the deps arent modified
<clever> le_jonge: and the new mkDerivation can append ghcid to the inputs
<clever> le_jonge: line 47 loads the stack2nix output, 51 passes it a set of overrides, and and 99 overwrites mkDerivation
<clever> le_jonge: which also means rebuilding every single package
<clever> le_jonge: you would need to create a new default.nix that overrides mkDerivation to add ghcid to every single package in your tree
<clever> not wanting to close the nix-shell because re-opening causes a 2 hour recompile
<clever> it automatically switches to the wrong derivation
<clever> for example, it makes it imposible to run `nix-build` inside a `nix-shell`
<clever> le_jonge: i try to avoid pkgs.lib.inNixShell, it tends to just cause more confusion
<clever> -p auto-generates a nix file and loads it
<clever> le_jonge: -p cant be mixed with nix files
<clever> ghcid is installed system wide, too much of a bother to override it into literally 100's of different derivations
<clever> le_jonge: nix-shell default.nix -A foo.env -> runhaskell Setup.hs configure ; ghcid -c "runhaskell Setup.hs repl"
<clever> le_jonge: i use ghcid with stack2nix all the time
<clever> le_jonge: add .env to the attribute and ghcid works fine
<clever> and since you didnt give it an attr, it builds all
<clever> manveru: it may be an attrset, containing an attr for every single package
<clever> manveru: try importing that file in nix repl
<clever> you can just skip -I entirely, and put the paths right into the file
<clever> then run nix-shell against that file
<clever> let pkgs1 = import /path/to/nixpkgs1 {}; pkgs2 = import /path/to/nixpkgs2 {}; in pkgs1.stdenv.mkDerivation { name = "name"; buildInputs = [ pkgs1.foo pkgs2.bar ]; }
<clever> create a nix file with something like this:
<clever> nschoe: you need to write your own nix expression, that imports the right paths
<clever> nschoe: you can use multiple -I's, but only one that sets nixpkgs= will take effect
<clever> nixpkgs.overlays = [ (self: super: { something = super.something.override { hostname = config.networking.hostname; }; }) ];
<clever> it would just be a variant of the example i just gave, with strings instead of bools
<clever> you could also do that
<clever> and then in nixos, nixpkgs.overlays = [ (self: super: { something = super.something.override { doHadexThing = true; }; }) ];
<clever> { stdenv, doHadexThing ? false, ... }:
<clever> kalbasit: you can make it an argument to the package, that is boolean, and then override that from nixos
<clever> not the nixpkgs layer
<clever> kalbasit: your configuration.nix has to conditionally change the overrides
<clever> kalbasit: correct, that is only in nixos
<clever> kalbasit: just use normal ++ and if statememtns
<clever> kalbasit: mkMerge only works in nixos, not nixpkgs
<clever> yeah, that will work fine
<clever> lo_mlatu: just the normal nix-collect-garbage
<clever> Lisanna: and ,locate just uses nix-index, which you can install locally
<clever> iqubic: its also in the psmisc package
<clever> ,locate killall

2018-07-17

<clever> logzet: id just switch to unstable
<clever> which forked ~4 months ago
<clever> so its not in the website, which is for 18.03
<clever> logzet: git blame says the option was added 3 months ago
<clever> logzet: mkEnableOption uses the string given to it to generate a description
<clever> logzet: the module will use that to override virtualbox for you, just before the module uses it
<clever> logzet: there is a dedicated virtualisation.virtualbox.host.enableExtensionPack = true; option in the nixos module itself
<clever> logzet: they let you modify the pkgs set that the nixos module uses
<clever> logzet: thats what package overrides/overlays are for
<clever> the nixos module adds that for you
<clever> logzet: you should not ever be putting vbox into the systemPackages
<clever> logzet: can you gist the full configuration.nix?
<clever> logzet: what config are you using to try to enable the extension pack?
<clever> Lisanna: i believe its tied into the scheduling shares
<clever> Lisanna: i dont think so
<clever> logzet: and it correctly tells me that it needs an extension pack if i select 2.0 or 3.0
<clever> logzet: ah, checking closer, my VM is configured with a 1.0 controller
<clever> logzet: vbox left the guest ISO's in /home/clever/.config/VirtualBox/VBoxGuestAdditions_5.2.8.iso
<clever> logzet: yeah, i'm talking about the guest additions, i have dynamic resizing and clipboard sharing working
<clever> logzet: i never enabled any overrides for it
<clever> logzet: when i hit the gui button to install the extensions, it just downloads an iso at runtime
<clever> iqubic: non-root can use any port over 1024
<clever> zduch4c: they are trying to fix the problem of sdl versions conflicting with eachother in the same /usr/include, which nix entirely prevents
<clever> zduch4c: SDL is being stupid, the headers are in $out/include/SDL2/ and you must manually add -I${sdl2}/include/SDL2 (or use pkgconfig)
<clever> iqubic: pretty much
<clever> iqubic: you can also: nix-env -f default.nix -iA package
<clever> iqubic: correct
<clever> iqubic: it likely lacks a build phase
<clever> iqubic: yes
<clever> all 3 of them are the same thing
<clever> package is your package
<clever> shell is only for nix-shell use
<clever> tarball, is the tarball containing your source
<clever> depending on what you want to build
<clever> iqubic: you need to pass one of: -A tarball, -A package, or -A shell
<clever> iqubic: and can you gist the nix file you ran nix-build on?
<clever> iqubic: what do the 3 symlinks point to?
<clever> iqubic: you pointed nix-build to an attribute set containing 3 attributes
<clever> and darwin has a second nix-daemon.sh that you source instead
<clever> ah
<clever> wpcarro: su always asks for the root password
<clever> manveru: run this on the storepath for your compiled binary, then pastebin the result
<clever> [root@amd-nixos:~]# du --max=0 -hc $(nix-store -qR /run/current-system) | sort -h
<clever> wpcarro: what errors are you getting?
<clever> manveru: nix-store --query --deriver
<clever> gchristensen: possibly
<clever> gchristensen: the problem
<clever> gchristensen: it may have moved to a path not being copied
<clever> tilpner: the cache is in ~/.cache/nix/tarballs
<clever> gchristensen: it feels more random, and any slight changes cause the problem to move to a different path
<clever> infinisil: i think it will wait
<clever> infinisil: after setting it up, run `systemctl list-timers`
<clever> gchristensen: after line 181, try to query the hash of iana
<clever> gchristensen: yeah, thought so, its loading a closure into a fake state dir, then copying to a 2nd store
<clever> gchristensen: nix show-derivation /nix/store/wdjkc55pv4vqnld5j3zrz9schzyxc4hx-nixos-disk-image.drv
<clever> so it must be doing something funky to allow that
<clever> so you cant access db.sqlite or nix-daemon when doing `nix copy` inside nix-build
<clever> but recursive nix is not finished
<clever> then copying to an image later
<clever> gchristensen: ahh, so it appears to be making a storedir inside a storepath
<clever> gchristensen: usually, the mkfs is ran inside the qemu, as is the nix copy
<clever> gchristensen: and if you make an override to run the same query inside the qemu instance?
<clever> gchristensen: what path is coming up wrong now, and what is the hash on each end?
<clever> gchristensen: is any of this building against master?
<clever> gchristensen: weird
<clever> gchristensen: ?
<clever> Pneumaticat: services.toxvpn = { enable = true; localip = "10.x.y.z"; }; and then run toxvpn-remote and its help sub-command to link the peers up
<clever> Pneumaticat: i simply have 2 IP's that work for reaching some machines, and 1 IP always works
<clever> Pneumaticat: the vpn doesnt change the default gateway, so i can choose to use it or not on a per-connection basis
<clever> Pneumaticat: at all times
<clever> d1rewolf_: yeah, that is rather strange
<clever> Pneumaticat: i run nixops on my laptop, and i have a VPN setup, so it can still reach all the machines in the cluster
<clever> d1rewolf_: yep
<clever> yep
<clever> gchristensen: i have also run into 9plan bugs, where a directory has totally wrong contents, try to ls glibc inside the derivation, inside qemu, if you can
<clever> so it has to nix-store --verify --check-contents inside the build every single time
<clever> gchristensen: and that closure export lacks hashes
<clever> gchristensen: the qemu uses 9plan to mount the host nix store, and a closure export to limit its db.sqlite to just the closure of that build
<clever> gchristensen: do you know if its running qemu inside linuxkit, to generate the nova image?
<clever> grep nixpkgs for fetchpatch to find examples
<clever> acowley: you probably want to run fetchpatch over that url first
<clever> local-echo is still enabled though, so passwords will leak in that shell
<clever> now all the console spew is in a terminal, and i have a login prompt when it finishes booting
<clever> d1rewolf_: yeah, hit e at grub, and add console=ttyS0 to the kernel, then f10 to boot
<clever> d1rewolf_: then you need something else...
<clever> d1rewolf_: that will route com1 to the terminal
<clever> d1rewolf_: https://imgur.com/a/Kv37fMB and run `socat stdin tcp-listen:1234` in another terminal
<clever> gchristensen: yeah
<clever> d1rewolf_: one min
<clever> d1rewolf_: dang, nothing obvious to me, all i can think of is to try and enable a serial console
<clever> d1rewolf_: they arent, thats why i keep my config in a git repo and also have zfs snapshots
<clever> d1rewolf_: can you screenshot it when its hung and upload that somewhere?
<clever> d1rewolf_: what changes where made to the config?
<clever> d1rewolf_: `journalctl -b -1` will filter it to the prebious boot
<clever> d1rewolf_: ah
<clever> d1rewolf_: but if you have a dedicated usb keyboard, you could forward that in
<clever> d1rewolf_: dang, i checked and it doesnt, only options to insert some combos
<clever> d1rewolf_: virtualbox may have checkboxes in the menu to hold ctrl and alt
<clever> gchristensen: id run `nix-store --delete` on the remote one, and then try the build again
<clever> gchristensen: one option is to tar it up on the remote end, then `ssh remote 'cat foo.tar' > foo.bar`
<clever> gchristensen: ah
<clever> gchristensen: any update?
<clever> gchristensen: try to rsync them into the same machine, and then run `diff -ru` on the 2 to see how they differ
<clever> gchristensen: i suspect that either the remote slave has a corrupt copy of glibc, or you built your own before hydra, and the build is not deterministic
<clever> gchristensen: sha256:1l5kld8dcqjw is the correct hash according to https://cache.nixos.org/2kcrj1ksd2a14bm5sky182fv2xwfhfap.narinfo
<clever> gchristensen: what does it return?
<clever> gchristensen: and if you run this on the linuxkit machine: nix-store --query --hash /nix/store/2kcrj1ksd2a14bm5sky182fv2xwfhfap-glibc-2.26-131
<clever> gchristensen: is 9plan at play?
<clever> gchristensen: can you run `nix-store --query --hash` on the problem storepath, on both machines?
<clever> gchristensen: yeah
<clever> d1rewolf_: the one in nix-env has priority, so you wont be getting any updates configuration.nix brings in
<clever> d1rewolf_: and roots profile is also available to all users
<clever> d1rewolf_: you can also `nix-env -q` to list what is currently installed in the user profile
<clever> d1rewolf_: yeah
<clever> d1rewolf_: and also remove them from nix-env
<clever> rydnr: ^^^
<clever> rydnr: it may help to read something like <setup.sh> and learn how the stdenv works
<clever> so i try to use boot instead
<clever> switch can get funky with such major version changes
<clever> so you need to reboot next
<clever> rydnr: `nixos-rebuidl boot` sets up grub to run the new version when you reboot
<clever> yay
<clever> rydnr: try _NIXOS_REBUILD_REEXEC=1 nixos-rebuild boot --fast
<clever> rydnr: and is this in root or via sudo?
<clever> rydnr: what does `which nix-build` print?
<clever> rydnr: then nixos-rebuild boot --fast
<clever> rydnr: then add its bin dir to $PATH, at the start
<clever> rydnr: that will download nix 2.0.4
<clever> > "nix-store -r ${nix}"
<clever> rydnr: revert the schema change, and then run...
<clever> i find it "simpler" to just memorize every type of URL github can do, and shove revs in as needed, lol
<clever> drbrule: the download link in the top right corner
<clever> drbrule: you can also check the branches on nixpkgs-channels
<clever> drbrule: i used https://howoldis.herokuapp.com/
<clever> nh2: try this: sqlite.override { stdenv = makeStaticLibraries stdenv; }
<clever> nh2: default flags in the stdenv
<clever> drbrule: i put the latest rev from nixos-unstable in the url
<clever> nh2: let me find it...
<clever> drbrule: its best to set it to a single rev, so it doesnt change
<clever> nh2: by default, nixos doesnt do very much static linking
<clever> 2018-07-17 11:53:19 < clever> drbrule: something like this would be a good start: export NIX_PATH=nixpkgs=https://github.com/nixos/nixpkgs/archive/dae9cf6106d.tar.gz
<clever> drbrule: if you do the export i gave above, then it will find the bootstrap nixpkgs
<clever> drbrule: then uses that to download the nixpkgs defined in the json
<clever> drbrule: it loads nixpkgs from $NIX_PATH
<clever> drbrule: your bootstrap nixpkgs needs a NIX_PATH
<clever> drbrule: something like this would be a good start: export NIX_PATH=nixpkgs=https://github.com/nixos/nixpkgs/archive/dae9cf6106d.tar.gz
<clever> drbrule: and you really want to set it to a specific revision, so the nixpkgs doesnt change without warning
<clever> drbrule: NIX_PATH is blank by default, you need to set it yourself
<clever> i still have a gentoo in the house, and a few ubuntu in the cloud
<clever> and its recursive like imports, so you can make a tree of files, that require more
<clever> slabity[m]: you can put require = [ ./trivial.nix ./trivial-vbox.nix ./your-other-files.nix ]; into a single nix file, and then run `nixops create` on that single file
<clever> gchristensen: nixops also allows you to make a tree of files, similar to imports in nixos
<clever> i need to head to bed now, its 1am
<clever> then you want something that can cache the builds
<clever> iqubic: do you want fast or slow builds?