2019-01-23

<clever> and then all disk based operations fail
<clever> leotaku: due to the nix sandbox, it tries to open "unknown" rather then "/etc/mtab"
<clever> leotaku: as a random example, net-snmp will check for the existance of files in /etc/ to during ./configure, and bake the answer into the source
<clever> yayforj: run nix-shell on the .drv file
<clever> > "${./doesntexist}"
<clever> > "${/pkgs}"
<clever> tilpner: and it just feels wrong :P
<clever> tilpner: it may throw an exception in the future, when paths to non-existant files become an error
<clever> tilpner: thats an absolute path to a file that doesnt exist, which is then blindly being turned into a string, and concat'd on
<clever> tilpner: you want to quote that part of the path
<clever> tilpner: /pkgs/applications is an abolute path, starting at /, the root dir
<clever> Dedalo: if you have a channel called nixos-hardware, then you can use <nixos-hardware/common/pc/laptop/cpu-throttling-bug.nix>
<clever> Dedalo: add just that file to your imports list
<clever> lists all generations
<clever> [root@amd-nixos:~]$ nix-env --profile /nix/var/nix/profiles/per-user/root/channels --list-generations
<clever> bgamari, slack1256: this will list all "packages" installed in generation 69
<clever> [root@amd-nixos:~]$ nix-env --profile /nix/var/nix/profiles/per-user/root/channels-69-link -q
<clever> iqubic: nix-env -iA nixpkgs.haskellPackages.cabal-install
<clever> and cabal2nix will support both
<clever> iqubic: and extra-libraries tells cabal to just -lfoo
<clever> iqubic: i'm guessing that pkgconfig-depends, will tell cabal to obey the include/link flags in the .pc file
<clever> yeah
<clever> cabal2nix doesnt have to do anything special with c-sources, thats entirely handled by cabal at build-time
<clever> c-sources is wrappers included with the haskell source, that do things like implement something haskell cant do, and haskell then ffi's into it
<clever> pkg-config is pre-installed stuff to find using pkgconfig
<clever> thats for when you have c code in the same project as the haskell, and it should build both at once
<clever> unknown, try one and see what happens
<clever> try both, see what happens
<clever> unknown
<clever> extra-libraries: panel ncurses pthread
<clever> iqubic: pkgconfig-depends: ncurses, panel
<clever> iqubic: you can define the non-haskell deps in the cabal file, and cabal2nix will translate them
<clever> which will then see the Setup.hs and run it
<clever> which will then see the Setup.hs and run it
<clever> will just call the main from cabal-install
<clever> main = defaultMain
<clever> import Distribution.Simple
<clever> the default file:
<clever> infinisil: infinite recursion
<clever> and nix only provides Cabal (the haskell library) not cabal-install (the binary your used to)
<clever> infinisil: the generic-builder.nix in nixpkgs always uses Setup.hs, even if your project is missing it (a default one is provided)
<clever> iqubic: its more about the cabal version, `cabal` will not always be the right version, and that will break things for you later on
<clever> iqubic: 20mb
<clever> yep
<clever> that grabs the .env, then applies an override to make some haskell binaries, and some bash scripts, both available
<clever> your shell.nix opens the .env automatically
<clever> all haskell packages have a .env attribute, that is for use with nix-shell
<clever> iqubic: it will load the given file, and return the top-level value in that file
<clever> iqubic: you want callPackage ./foo.nix {} as well
<clever> iqubic: it will import the given file, then use functionArgs to query what args it accepts, then give it those args, from the set callPackage came from
<clever> > builtins.functionArgs ({ a, b ? 5 }: a + b)
<clever> it will then make all the deps of that derivation exist (downloading and/or building), and set the env vars from the derivation
<clever> iqubic: nix-shell will load either shell.nix or default.nix, in either case, the file it loads must return a derivation (or a set, when using -A)
<clever> iqubic: it will read the derivation that the default.nix returns, make sure all the deps of that derivation exist in /nix/store/, and then set the env vars in the derivation
<clever> CMCDragonkai: unknown
<clever> iqubic: nix run or nix-shell
<clever> CMCDragonkai: https://www.freedesktop.org/wiki/Software/libtsm/ may be of use
<clever> CMCDragonkai: oh, i had something related open just a few days ago...
<clever> CMCDragonkai: yeah
<clever> iqubic: the only reason ive ever had to use cabal, was for `cabal init`, which creates Setup.hs and your cabal file
<clever> iqubic: because they dont know about Setup.hs
<clever> iqubic: yes
<clever> CMCDragonkai: some random examples of pty programs: xterm, sshd, screen, tmux
<clever> CMCDragonkai: a private instance of /dev/pts/ptmx is mounted into every nix sandbox, so any library that creates a pty can be used
<clever> iqubic: so you can just `runhaskell Setup.hs configure` or `ghcid -c "runhaskell Setup.hs repl"`
<clever> iqubic: `runhaskell Setup.hs` == cabal
<clever> CMCDragonkai: was already thinking about that, after i noticed curses in the comments
<clever> CMCDragonkai: nix-shell sets up the same env vars that nix-build would have been using to do the build, so you can always access the src it would have been building
<clever> CMCDragonkai: and running nix-shell on the .drv will point $src to it, and the genericBuild function will unpack that source for you
<clever> CMCDragonkai: the .drv depends on the source, so it must exist in /nix/store/
<clever> fresheyeball: also, you can replace `{ gitignore = gitignore; }` with `{ inherit gitignore; }`
<clever> CMCDragonkai: most of the time, you can also skip the -K, and just reproduce the failure in nix-shell, but it depends on whats failing, and if you want to wait for another build
<clever> fresheyeball: so you want `--arg pkgs 'import ./pkgs.nix'`
<clever> fresheyeball: pkgs.nix doesnt accept any arguments
<clever> ah, there
<clever> CMCDragonkai: and you can ignore env-vars
<clever> CMCDragonkai: you can use nix-shell to open the right shell, then cd into the dir left-behind from nix-build -K
<clever> fresheyeball: and pkgs.nix?
<clever> CMCDragonkai: your missing the entire stdenv
<clever> CMCDragonkai: 2019-01-22 22:14:21 < clever> also, i open the shell for this, by running `nix-shell /nix/store/foo.drv` on the drv that failed to build
<clever> CMCDragonkai: that will run any preCheck and postCheck hooks that may have been set
<clever> can you pastebin both mything.nix and pkgs.nix?
<clever> i think you want -A mything ?
<clever> fresheyeball: oh, i see the problem 'nix-build mything' told it to open a file called mything, rather then default.nix
<clever> but it would be better to just have a default, { pkgs ? import ./pkgs.nix {} }:
<clever> oh wait, what you gave might work...., if pkgs.nix accepts an empty set
<clever> and you must use -E if its an expression
<clever> you must pass it the pkgs if it lacks a default
<clever> fresheyeball: nix-build -E 'with import <nixpkgs> {}; callPackage ./file'
<clever> yeah, thats what -R does
<clever> just chown it over to your user
<clever> CMCDragonkai: you dont own that folder, chown -R it
<clever> and then manually try the 2nd line, and see if it fails again
<clever> echo "$installCheckPhase"
<clever> quote the variable, or the \n's get eaten
<clever> is that set to anything?
<clever> also, i open the shell for this, by running `nix-shell /nix/store/foo.drv` on the drv that failed to build
<clever> you may also want to see if the checkPhase is defined to anything, `echo "$checkPhase"`
<clever> youll want to first cd into asciimatics-1.10.0
<clever> CMCDragonkai: then you need to lookup the python way to run tests
<clever> CMCDragonkai: depending on the package, it could just be `make check` or `make tests`
<clever> mankyKitty: nix-tools also has cross-compile support
<clever> until something else changes like your nixpkgs rev
<clever> but once its built once, its cached locally
<clever> ah
<clever> mankyKitty: and nix should cache things, and only build it once
<clever> mankyKitty: does it really take that long to build the executable?
<clever> mankyKitty: not seeing any obvious flag to just turn off executables
<clever> runhaskell Setup.hs configure --help | grep exe --color
<clever> mankyKitty: if you could find a cabal flag to just disable all executables, you could use configureFlags to pass it in
<clever> but that just flips executables between static and dynamic, i believe
<clever> enableSharedExecutables controls the usage of --executable-dynamic at the cabal level
<clever> ah, thats a helper function, that sets enableSharedExecutables
<clever> enableSharedExecutables is however
<clever> also not a valid flag
<clever> doesnt exist in nixpkgs
<clever> anoyingly, json2yaml isnt built by default, so i need an override to bring it back
<clever> mankyKitty: compare that to the json2yaml executable, http://hackage.haskell.org/package/yaml-0.11.0.0/yaml.cabal
<clever> mankyKitty: there is no flag for that in the cabal file, so i dont think its a simple task to turn off, http://hackage.haskell.org/package/hw-json-0.9.0.1/hw-json.cabal
<clever> mankyKitty: which dependency, and which executable?

2019-01-22

<clever> seqizz: network_aws.nix defines the ec2 key, and adds aws.nix to awsDeploy
<clever> seqizz: network.nix defines network wide params, and a machine called awsDeploy that uses base.nix
<clever> seqizz: https://gist.github.com/cleverca22/34932459b4254d5e1b8d9a5025d77fc1 and use `nixops modify -d something network.nix network_aws.nix`
<clever> gist*
<clever> seqizz: i'll put an example in git
<clever> seqizz: you want to move 17-35 into the base.nix, and put the imports inside near deployment = {
<clever> seqizz: aws.nix is a nixos module, resources is not valid in that context, and line 17 of the pastebin is nixops syntax
<clever> seqizz: base.nix is a nixops file, imports is not a valid key in that context
<clever> seqizz: and what does `nixops info` say?
<clever> rycee: that var is just `xfce` on my end
<clever> seqizz: that shouldnt be working
<clever> seqizz: wait, somethings not right, line 8 (deployment) is a nixos option, but line 2 is a nixops option
<clever> seqizz: line 8 should be machinename = { resources, ... }: {
<clever> it was down several pages
<clever> ar1a: there is also the `nixos-option` command, `man configuration.nix` and https://nixos.org/nixos/options.html
<clever> ar1a: its a side-effect of being bored, and literally reading the name of every single nixos option in the manual
<clever> ar1a: services.openssh.startWhenNeeded = true;
<clever> either via a stub in a fat32 fs you never touch, or by hacking the firmware
<clever> my understanding, is that you just need to load the final .efi file at boot, somehow
<clever> This is a GPLv3+ implementation of standalone EFI File System drivers, based on the GRUB 2.0 read-only drivers.
<clever> Mic92: yeah, i wouldnt trust grub with zfs, but its just an example of the insanity you could do
<clever> maybe even zfs??
<clever> combine the 2, risk bricking your motherboard, and boom, your ESP can be any partition grub supports!
<clever> Mic92: and there is another project, that took all of the FS drivers in grub, and packaged them into efi binaries
<clever> Mic92: i dont remember the link, but there are tools to unpack a bios, then repack it with extra efi binaries added in
<clever> if you do choose to use a fat32 /boot/EFI and ext4 /boot/ (or even /boot on /), you must set boot.loader.efi.efiSysMountPoint = "/boot/EFI";
<clever> technically, only that subdir has to exist on fat32
<clever> gchristensen: its /boot/EFI
<clever> gchristensen: wait, wrong path
<clever> oh, that will need testing and fixing, i use grub, so havent ran into that
<clever> fix the guide to rely on fat32 for even fewer files?
<clever> and in that case, sticking to os.rename would give you protections
<clever> Mic92: note, it is possible to make /boot/ESP fat32, and then /boot/ ext4
<clever> os.rename is atomic, so it either replaced the file, or it didnt happen
<clever> which could brick the machine
<clever> and if the machine has an improper shutdown, then the file will be partially written
<clever> shutil.move will overwrite the file, as it copies
<clever> gchristensen: one reason you should stick with os.rename
<clever> you could also make the temp file in /boot/ to begin with, like /boot/loader/entries/.temp
<clever> the `mv` binary falls back automatically
<clever> gchristensen: you need to instead copy the file, then delete the source, when rename failed
<clever> gchristensen: os.rename uses the rename syscall, which can only work within a single filesystem
<clever> ilya-fedin: and the callPackage in all-packages.nix defaults it to the config.android_sdk.accept_license
<clever> ilya-fedin: i think thats entirely a .override for licenseAccepted
<clever> and env vars can be set system wide
<clever> the unfree error tells you the env var
<clever> ilya-fedin: a: put all overrides in /etc/nix/nixpkgs-config.nix, b: make a config.nix for all users, c: there is an env var to allow unfree
<clever> either put the override into /etc/nix/nixpkgs-config.nix or just delete /etc/nix/nixpkgs-config.nix
<clever> ilya-fedin: /etc/nix/nixpkgs-config.nix has priority, and makes nixpkgs ignore all other config.nix files
<clever> what files does this find? ls -lh $NIXPKGS_CONFIG ~/.config/nixpkgs/config.nix ~/.nixpkgs/config.nix
<clever> ilya-fedin: you want pkgs.lib which comes from `packageOverrides = pkgs: ...`
<clever> ilya-fedin: what files does this find?
<clever> ls -lh $NIXPKGS_CONFIG ~/.config/nixpkgs/config.nix ~/.nixpkgs/config.nix
<clever> ilya-fedin: and why does line 1 have stdenv, ... in it?
<clever> ilya-fedin: what path did you put that config.nix at?
<clever> r5d: it can automate the testing, but ive never used that mode
<clever> if the crash isnt easy to trigger, then things get a lot harder to bisect
<clever> r5d: you would need to boot windows, using the qemu it just built, and try to crash it again
<clever> git will then check revs out for you, and just keep building, testing, and saying if its good or bad
<clever> then checkout the bad rev, build, confirm its bad, and `git bisect bad`
<clever> r5d: clone nixpkgs, checkout the nixpkgs rev you know works, nix-build -A qemu, ./result/bin/qemu ..., and once you confirm its good, `git bisect good`
<clever> r5d: one trick, is to use a bisect in nixpkgs
<clever> ivegotasthma: its possible that packages.html isnt set to recurse into nodePackages
<clever> nix-repl> nodePackages.node2nix
<clever> seqizz: but sometimes you can: (pkgs.callPackage ./foo.nix {}).buildInputs
<clever> seqizz: if it was returning a set, yeah, but if its a chunk of code that calls a function, its more ocmplex
<clever> to run that script
<clever> dgarzon: in this case, line 94-96 will // a set of utils onto the main shell env, so i can nix-shell -A fixStylishHaskell
<clever> dgarzon: the only way to impurely mutate something, in a semi-pure way, is to run a derivation like this via nix-shell, https://github.com/input-output-hk/cardano-sl/blob/develop/shell.nix#L57-L74
<clever> dgarzon: you can apply mutations, but the result will be in a copy in $out
<clever> and nix-build will then create a symlink called result, that points to that $out
<clever> dgarzon: you can never write to the current directory, all writes must go to the $out dir (you might need to mkdir $out first)
<clever> oskar: and interactiveShellInit is nixos only, it wont work in config.nix
<clever> oskar: oh, and line 6, your assigning the pkgs attribute, which breaks everything
<clever> oskar: pkgs.callPackage
<clever> Laalf: that /etc/ is the host doing the install, not the target your installing to
<clever> you must use a relative path like ./hardware-configuration.nix, so it will not care that the cfg is currently under /mnt/
<clever> Laalf: i believe the problem is line 5 of http://paste.debian.net/1061934/, its loading the wrong hardware-configuration.nix
<clever> yep, that one is also right
<clever> Laalf: and what is in your hardware-configuration.nix file?
<clever> ah, 63246fd1
<clever> Laalf: what about blkid /dev/vg/root ?
<clever> oskar: re-install/build whatever is affected
<clever> Laalf: is the correct rootfs mounted to /mnt/ when you run `nixos-generate-config --root /mnt/` ?
<clever> Laalf: you need to change configuration.nix to use ./hardware-configuration.nix, rather then /etc/nixos/hardware-configuration.nix
<clever> Laalf: nope
<clever> so it works relative to where configuration.nix lives
<clever> Laalf: in general, you use ./hardware-configuration.nix
<clever> Laalf: and what about hardware-configuration.nix?
<clever> Laalf: line 30 should open the lvm device, and then do `vgchange -a y`, so then the rootfs will be visible...
<clever> Laalf: ah, reading the link closer, i believe you want the uuid of the luks device, which one did you insert?
<clever> dgarzon: ${./foo}
<clever> you could even jam that string into a shell.nix file, and then just copy it to every project
<clever> the above nix-shell command auto-does everything
<clever> jomik: or a cabal file that depends on those 4 things
<clever> jomik: then you want -p
<clever> Laalf: and also pastebin your configuration.nix
<clever> Laalf: if you boot the install media again, and run `cryptsetup luksOpen ...` and `vgchange -a y`, what does `blkid` say about the rootfs?
<clever> for most haskell packages, that will just work
<clever> this will load a shell suitable for foo.cabal
<clever> nix-shell -E 'with import <nixpkgs> {}; (haskellPackages.callCabal2nix "foo" ./. {}).env'
<clever> hydra will iterate over the entire .drv tree, and add roots for every derivation
<clever> if you dont --max-freed, then all garbage is gone on every GC
<clever> fresheyeball: that will leave some garbage behind, so the random order of deletion will actually allow some garbage to survive
<clever> fresheyeball: this --max-freed flag, tells it to stop GC'ing after it hits 64gig free
<clever> gchristensen: still only runtime closure, not buildtime
<clever> or stop GC'ing everything
<clever> switch to hydra? :P
<clever> also, nix-build's result symlink, overwrites the old result symlink, so it can only keep 1 thing
<clever> fresheyeball: only hydra has support to root the entire build-time closure
<clever> fresheyeball: but, that only roots the final result, not the build-time deps
<clever> fresheyeball: and --older-than will never delete result links
<clever> fresheyeball: nix-build always outputs a result symlink, that is a root
<clever> fresheyeball: so you dont have this problem with hydra
<clever> fresheyeball: hydra will add a GC root for the last X builds
<clever> fresheyeball: correct, and if you uninstall, or upgrade, the old version will also be "in use"
<clever> then start deleting from the head, until it hits --max-freed
<clever> simpson: it will then std::shuffle that entire list
<clever> simpson: it will gather all garbage in /nix/store/ into a std::list
<clever> fresheyeball: any nix-env or nixos-rebuild generate, that is older then 2 weeks
<clever> it is truely random, let me grab the source
<clever> simpson: one sec
<clever> the root says "never delete this thing"
<clever> fresheyeball: garbage collector roots
<clever> using --max-freed to stop it from deleting ALL garbage is the only solution
<clever> un-rooteded stuff (nix-shell) is still at risk
<clever> after removing roots, it will then remove garbage in /nix/store in a random order
<clever> --delete-older-than only controls what roots it will delete
<clever> xourt: probably need to add libclang to inpuits
<clever> ,locate Decl.h
<clever> the tools for generating such a tar also include a dummy nix db "dump", that you can then restore, so the closure in the tar is "valid"
<clever> nh2: if you can build nix on a riscv nixos, you can just tar up the closure of it
<clever> its basically a custom distro, heavily modeled on nixos (and borrowing some nixos modules), but uses runit rather then systemd, and a large amount of junk is missing
<clever> ingenieroariel: on x86, it compiles down to a 40mb squashfs, which contains the entire rootfs
<clever> ingenieroariel: https://github.com/cleverca22/not-os
<clever> ingenieroariel: you may be interested in not-os
<clever> das_j_: nix-store -q --tree confirms, systemd directly depends on kexec-tools
<clever> ingenieroariel: i think systemd depends on kexec
<clever> __monty__: nice
<clever> if it is a dir, then i believe it will open default.nix in that dir
<clever> and the file on the cmdline, can either be a file like foo.nix, a dir like ./bar/ or ., or a search path like <nixpkgs> (and quote it to stop bash)
<clever> * default.nix
<clever> * shell.nix
<clever> * the file given on the cmd line (if present)
<clever> for nix-shell, it will try to load things in this order:
<clever> __monty__: only nix run uses that type of syntax
<clever> it accepts the "path" to a default.nix to load
<clever> __monty__: then tell it to open nixpkgs, nix-shell '<nixpkgs>' -A hello
<clever> either kvm-amd or kvm-intel
<clever> you need to modprobe the kvm driver for your cpu
<clever> and yeah, it will just fail due to a missing /dev/kvm if you force that
<clever> jonge: the syntax is just `system-features = kvm nixos-test` i think
<clever> gchristensen: yeah, i saw the release notes somewhere
<clever> jonge: is it happening with build slaves, or local builds?

2019-01-21

<clever> laas: src = ./.; or src = /home/clever/apps/foo;
<clever> Denommus: i think its just as simple as deleting ~/.nix-profile and /nix/
<clever> Denommus: depends on if you did a single or multiuser install, but why do you want to remove it?
<clever> aleph-: poking around with tab completion in `nix repl '<nixpkgs>'` found pythonPackages.buildPythonPackage
<clever> aleph-: what error does it give?
<clever> aleph-: does it give aaaaaaaany error when you run that?
<clever> send the logs elsewhere
<clever> the logs in the current dir, made ./. explode
<clever> oh
<clever> so the bad_alloc must be coming from elsewhere
<clever> fresheyeball: the only places nix can throw bad_alloc is in the evaluator, but nix-daemon never evals nix
<clever> lokado: and it should allow a login
<clever> lokado: nixos-install will ask for a root pw when the install is finished
<clever> src/libexpr/eval.cc: throw std::bad_alloc();
<clever> src/libexpr/eval.cc: if (!t) throw std::bad_alloc();
<clever> fresheyeball: then you shouldnt be seeing the E2BIG...
<clever> ctrl+alt+f4 is the escape code, but that can be disabled in xorg.conf
<clever> when X11 is running, alt+f4 will be sent to the running app, rather then switching to tty4