2019-10-31

<clever> m3thos: about all that is left is to run nixos-generate-config --root /mnt, and then copy configuration.nix over
<clever> zeta_0: it just needs to not match the hash of anything else you have previously downloaded
<clever> zeta_0: it just needs to be "wrong", i just throw on replace mode and turn a few digits into 0's
<clever> __monty__: yeah, not ideal, just a work-around until the bug in nix is solved
<clever> until the bug is fixed
<clever> __monty__: looks like enough info, about all i can think of is to set max-jobs to 0, so it never does a local build
<clever> graphical pulls in base, sets up kde, installs kate, copies a nixos manual to the desktop, and drops gparted and konsole links on the desktop
<clever> minimal just turns off fontconfig, and pulls in base
<clever> zeta_0: thats the biggest thing, let me grab the list...
<clever> zeta_0: minimal doesnt have kde installed on it
<clever> __monty__: the -A thing is actually newer!
<clever> __monty__: try just plain old nix-prefetch-url on that url?
<clever> __monty__: why does the package need different hashes for each platform?
<clever> yeah
<clever> definitely a nix bug then, -keep-going should have kept going!
<clever> __monty__: but does it continue to build hscolor and jailbreak-cabal?
<clever> to just build that thing again
<clever> __monty__: you can do things like: nix-store -r --keep-going /nix/store/jd6vw7rls6d9j24kq8fc3pc28f0psc37-home-manager-generation.drv
<clever> __monty__: it might be a bug in nix then, what happens if you build with --keep-going?, and then retry each time it fails
<clever> __monty__: and what is in /etc/nix/machines ?
<clever> __monty__: what is the exact output when nix begins to build locally?
<clever> __monty__: not sure then
<clever> __monty__: also, ghc depends on happy, which it gets from another haskell packages set
<clever> __monty__: are you sure that is the same happy.drv that it was building locally?
<clever> __monty__: what happens if you run nix-store -r on that drv?
<clever> __monty__: there should be a system features thing in the output
<clever> __monty__: run `nix show-derivation` on the .drv for the happy that is being built
<clever> nh2_: but the examples entries dont cover those cases
<clever> nh2_: for example, i want native arm->arm+musl, and i want cross anything->arm+musl
<clever> nh2_: something ive wanted, is musl and more cross-compile, and other arches
<clever> johnnywho: substituteAll will replace @out@ with the value of $out
<clever> infinisil: passAsFile may happen before that
<clever> johnnywho: try `substituteAll $ds9Path $out/bin/ds9` and use @out@ in the script?
<clever> one min...
<clever> you want substite then
<clever> oh wait, passAsFile
<clever> its already a normal env var by that point in time
<clever> johnnywho: just do `cd $out` there
<clever> johnnywho: how are you using it?
<clever> johnnywho: it only does it in certain places, i havent figured out exactly where
<clever> johnnywho: nix will replace /1rz4g4znpzjwh1xymhjpm42vipw92pr73vdgl6xs1hycac8kf2n9 with the value of $out at a later stage
<clever> Miyu-saki: there is literally a component, between keyboard and chair, that makes the "touchscreen" work!
<clever> Miyu-saki: just tell her its a pebkac
<clever> Miyu-saki: lol
<clever> i was at that table during the nixcon hackday
<clever> yes
<clever> Miyu-saki: yes
<clever> Miyu-saki: no, full blown nixos, in the system partition
<clever> Miyu-saki: you should try nixos on an android device, that will be fun!
<clever> xd1le: if you do explicitely set a phase, the pre/post hooks will cease to run (enless you add the runHook's back in yourself)
<clever> pie_: you can use self.callPackage to get things from self, and pkgs is the fallback
<clever> pie_: this takes something in the form of (self: { ... }) and turns it into a set with extend and callPackage
<clever> pie_: i think it may just need some better guidelines on how to document it, and make things more reproducable
<clever> pie_: some failures are with nix itself, not setting the right env vars when it launches a build
<clever> pie_: depends on if the problem is at build time or when running the built result
<clever> DigitalKiwi: but with haskell and some muxing, you can run multiple things in the child proc at once, and not mix the outputs up
<clever> DigitalKiwi: for example, with the perl framework, you can only run one thing at once
<clever> DigitalKiwi: using a proper muxed rpc over the serial port also adds more options
<clever> ghc is only needed to compile the test runner, which only changes rarely (when editing tests, or a mass-rebuild)
<clever> and for those that dont want to do complex stuff, the default guest functions can support what we already have
<clever> and the guest proc can be as complex or simple as it needs to be
<clever> then, rather then have to smuggle files around thru echo and 9plan, you can just send a signal to the guest proc, and it can do complex actions on its own
<clever> DigitalKiwi: what i want, is some haskell code, that runs in both the host and guest, and uses a binary rpc to coordinate between the 2 halves
<clever> DigitalKiwi: and then parses the result to find the EOF and exit code
<clever> DigitalKiwi: it basically does `(foo);echo '|!EOF' ?$` over a serial console
<clever> DigitalKiwi: first, have you seen how $machine->run works?, and gets exit codes!
<clever> DigitalKiwi: ive been wanting to use haskell for the nixos test framework, for a few reasons
<clever> yeah
<clever> and can re-call it with different args
<clever> and it basically saves the un-called version of the function within default.nix
<clever> its callPackage that adds .override to the result
<clever> overrideDerivation works below mkDerivation, and wont play nicely with cross-compile flags
<clever> overrideAttrs works at the stdenv.mkDerivation level
<clever> override acts at the callPackage level
<clever> probably
<clever> pie_: can also throw in a lib.cleanSource ./.
<clever> pie_: nix-build -E 'with import <nixpkgs> {}; hello.overrideAttrs (old: { src = ./.; })'
<clever> then users cant randomly break it
<clever> to stop it from obeying any user specified config
<clever> tbenst: i prefer doing { config = {}; overlays = []; } for some things
<clever> tbenst: enless the derivation does `import <nixpkgs> { overlays = []; }`
<clever> tbenst: nix-build should obey that
<clever> infinisil: nix-diff can tell you why they differ

2019-10-30

<clever> evanjs: and i think those are named after a hash of the url, so all of the above greps fail
<clever> evanjs: oh, it may have been a lock file in ~/.cache/nix/tarballs
<clever> evanjs: id check all of the above next time it happens, before pkill'ing things
<clever> evanjs: out of ideas then, do the microsoft thing, turn it off, then turn it back on! lol
<clever> evanjs: anything running as a nixbld user?
<clever> evanjs: try `nix-collect-garbage --max-freed 100m` ?
<clever> evanjs: `ls -l /proc/*/fd/* | grep channel-rust-beta` ?
<clever> evanjs: does that appear in any other open files?
<clever> evanjs: which thing is it locking?
<clever> evanjs: does the verbose output say which lock?
<clever> evanjs: hide those with grep or remove a v or 2
<clever> evanjs: if you run the nix build again with -vvvvv, does it show anything more?
<clever> evanjs: you want to grep the names of the things the symlinks point to, not their contents
<clever> evanjs: `ls -l /proc/*/fd/* | grep big-lock`
<clever> evanjs: oh wait, typo in the above
<clever> evanjs: any build machines involved in things?
<clever> evanjs: now check `ls /proc/*/fd/* | grep big-lock` and see if any other pid has it open
<clever> sauyon: that sounds like a normal multi-user install
<clever> evanjs: for the process that is hung on the lock file, check its /proc/PID/fd/ dir, do you see a lock file?
<clever> sauyon: theres where youll find the ca certs, in roots ~/.nix-profile, which can also be found at /nix/var/nix/profiles/default/
<clever> sauyon: what about `nix-env -q` as root?
<clever> sauyon: what does `nix-env -q` list?
<clever> sauyon: yeah, i dont see the ssl var there
<clever> evanjs: is there another nix-build or nix-daemon process running, for that build?
<clever> sauyon: try with the nix copy of curl
<clever> sauyon: the darwin curl or the nix curl?
<clever> sauyon: probably an env var to do with ssl ca's then
<clever> sauyon: is the date set right?
<clever> neiluj: nativeBuildInputs is for tools you run at build time, while buildInputs is for stuff your linking to
<clever> neiluj: gtk2 should be in the normal buildInputs list
<clever> neiluj: if pkgconfig is not in the inputs, then the other inputs wont be added to the pkgconfig search path
<clever> neiluj: did you also add pkgconfig to the nativeBuildInputs ?
<clever> zeta_0: yeah
<clever> zeta_0: you can use the nixos channel on any linux distro
<clever> Twey: these run on an arch of "builtin"
<clever> Twey: the builtin ones are the most restricted, because they are implemented in c++ within nix
<clever> Twey: eval time ones are the "worst" because they stall the eval and cant be done in parallel
<clever> Twey: there are 3 main types of fod, ones that build on "builtin", eval-time ones, and normal derivations

2019-10-27

<clever> AmandaC: lib.cleanSourceWith and give it a function to exclude .vscode
<clever> Raito_Bezarius: have you tried `git grep` ?
<clever> Raito_Bezarius: git gc wont delete history
<clever> AmandaC: lib.cleanSource
<clever> orbit234234: when in a string, yep

2019-10-25

<clever> pi3r: bbl
<clever> pi3r: what is `haskellPackages.language-puppet` in `nix repl '<nixpkgs>'` ?
<clever> pi3r: ah, but cabal is doing >=
<clever> pi3r: the version of language-puppet may have increased, and if cabal is saying <=, then it fails
<clever> pi3r: nope, always been like that
<clever> pi3r: you want to use doJailBreak
<clever> pi3r: nix doesnt obey the version restrictions when providing haskell packages
<clever> fendor: ar should be availble in the default stdenv
<clever> dminuoso: and that returns a set that contains config
<clever> dminuoso: <nixpkgs/nixos> refers to a default.nix at nixpkgs/nixos/default.nix
<clever> dminuoso: the repl command i gave loads nixos, which gives you a config attr
<clever> dminuoso: then you can just eval `config` in the repl
<clever> dminuoso: it will eval every nixos module, and your configuration.nix
<clever> dminuoso: `nix repl '<nixpkgs/nixos>'` will eval the entire nixos, and all modules configuration.nix refers to
<clever> Patrol02: https://nixos.org/nixos/options.html#lirc you must enable the service
<clever> jD91mZM2: ive seen a lot of people do that
<clever> wedens: all of the $out's from contents get merged into /
<clever> wedens: put the symlinks in $out/something of a derivation, and put that into the contents, i think
<clever> wedens: what are you needing to do?
<clever> wedens: thts why i never use runAsRoot
<clever> wedens: the build cant get real root, so its using qemu to get emulatoed root
<clever> > builtins.elemAt [ "a" "b" "c" ] 2
<clever> [200~> builtins.elemAt [ "a" "b" "c" ] 2
<clever> Maise: just buildPhase = "./build.sh";
<clever> Maise: so you just want ./build.sh
<clever> Maise: the unpackPhase copies $src to . for you, and cd's into the dir

2019-10-24

<clever> pingiun: so you want to run `unpackPhase`
<clever> pingiun: the unpackPhase will cpy $src to .

2019-10-22

<clever> sondr3: pkgs.runCommand, examples can be found all over nixpkgs, though configuring emacs to use the result might be tricky
<clever> yep
<clever> its just a regular old symlink
<clever> rm result
<clever> it will remain in /nix/store until you both remove result and collect garbage
<clever> same there, all it does is build things and make a result symlink
<clever> theres nothing to really undo with `nix-build`
<clever> ah, for that, you want either `sudo nix-channel --update ; nix-env -iA nixos.chromium` or remove it, add it to systemPackages, and do the previous
<clever> Cement: in general, sudo nixos-rebuild --upgrade switch
<clever> Cement: ?
<clever> hpfr[m]: anything the nixos-rebuild would have built (but was already built), and anything it needs in the future (sources for something it will build soon)
<clever> have you gotten a cross-compiler to produce a bit perfect replica of a native binary?
<clever> that relies on the build actually being reproducible
<clever> so it wont share products between native and cross
<clever> which compiler you use affects the hash of $out
<clever> it wont mix native and cross to suit the host arch
<clever> ah, no
<clever> li_matrix: if you set system to x86, but crossSystem to arm, and attempt to run the build on an arm machine, it will find the "nearest" x86 machine to do the job
<clever> li_matrix: not on its own, but you can configure it for cross-compiling
<clever> hpfr[m]: only what the current rebuild needs will be rooted, and only once the main build has started, IFD's and the eval mess things up a bit
<clever> li_matrix: sorta, a derivation has an arch its supposed to run on, and if the current machine cant run that arch, its forced to use a remote build machine
<clever> hpfr[m]: yeah, nothing the build needs can be gc'd during a build
<clever> just adding lib is the right one then
<clever> hpfr[m]: is this a package or configuration.nix?
<clever> hpfr[m]: stdenv.lib is another way to access lib
<clever> hpfr[m]: nix repl '<nixpkgs>'
<clever> hpfr[m]: and then concat, done!
<clever> [ /root/t/file ]
<clever> nix-repl> map (name: ./. + "/${name}") (builtins.attrNames (lib.filterAttrs (k: v: v == "regular") (builtins.readDir ./.)))
<clever> then extract the names only
<clever> [ "file" ]
<clever> nix-repl> builtins.attrNames (lib.filterAttrs (k: v: v == "regular") (builtins.readDir ./.))
<clever> first, filter it down to only files
<clever> nix-repl> lib.filterAttrs (k: v: v == "regular") (builtins.readDir ./.)
<clever> { file = "regular"; }
<clever> hpfr[m]: it returns an attribute set, with names for keys, and types for values
<clever> nix-repl> builtins.readDir ./.
<clever> { dir = "directory"; file = "regular"; }
<clever> then you can use map to concat it to a path
<clever> hpfr[m]: builtins.readDir will return the contents of a dir as a list
<clever> hpfr[m]: nope
<clever> ashkitten: unknown, but you can temporarily just set nix.package in configuration.nix
<clever> the fix is already in nix master, and will hold until you have >1024 channels, lol

2019-10-21

<clever> bsima: you have to add makeWrapper to your inputs
<clever> AmandaC: yeah, until its fixed
<clever> AmandaC: basically, the problem is when you have more entries in `nix-channel --list` then in `$NIX_PATH
<clever> Flambe: figure out what permissions its trying to adjust, and fix them manually
<clever> Flambe: due to how the steam fhs env works, it cant access sudo
<clever> there is now a `nix show-derivation /nix/store/foo.drv` to pretty-print things
<clever> 2016-08-31 12:07:25< clever> Seichi: ah, found it in an older chat log, nix-env -iA nixos.aterm ; pp-aterm -i foo.drv
<clever> 2016-01-23 20:26:57< roconnor> Sonarpulse: /nix/store/198lcy5p71xz2396ahvs1gsrsp0d4kym-strategoxt-1.8pre24429/bin/pp-aterm
<clever> 2016-03-05 19:24:22< Sonarpulse> I did a diff <(pp-aterm $(nix-instantiate ...) <(ditto)
<clever> 2015-09-14 22:21:18< Mathnerd314> McEnroe_: why do you need the configuration.nix? just use pp-aterm -i $(nix-store -q --deriver /nix/var/nix/profiles/system-<n>-link)
<clever> i believe it was pp-aterm
<clever> elux: so you need to `NIX_PATH=nixpkgs=. nixos/maintainers/scripts/gce/create-gce.sh`
<clever> elux: that just builds whatever <nixpkgs> from NIX_PATH maps to
<clever> systemd.services.netdata.path = [ pkgs.jq ];
<clever> octe: you can set that .path again, and nixos will merge things
<clever> so it wont wind up in the normal PATH
<clever> it will probably only add those packages to the PYTHONPATH
<clever> defines a function that takes 1 argument
<clever> octe: the default value is a function, that takes a set of python packages, and then returns a list of things
<clever> octe: the [] is just an empty list
<clever> elux: could be a bug in unstable

2019-10-20

<clever> elux: how are you switching to that user?
<clever> elux: does the new user have isNormalUser = true; set on it?
<clever> elux: do you have a .bashrc or something else, that is messing with $PATH?
<clever> then just apply nix-diff and some $(...)
<clever> and that, the drv for the current config (what you will have, if you nixos-rebuild switch)
<clever> [root@amd-nixos:~]# nix-instantiate '<nixpkgs/nixos>' -A system
<clever> that shows the .drv for whatever you currently run
<clever> [root@amd-nixos:~]# nix-store -q --deriver /run/current-system
<clever> smw_: for diffing, you want nix-diff
<clever> smw_: you can also just give it a more specific attr, and use tab completion
<clever> try `nix repl '<nixpkgs/nixos>'` and then `config.boot.loader`
<clever> jD91mZM2: thats going to cause infinite recursion
<clever> angerman: `nix-shell --pure /nix/store/foo.drv` should replicate the env vars right
<clever> angerman: then just tweak `$out`, and run `genericBuild`
<clever> angerman: if sandboxing isnt a concern, you can just run `nix-shell /nix/store/foo.drv` and it will set the same env vars
<clever> unknown! lol
<clever> wooo, it compiles! (but i had to disable c++ support)
<clever> /nix/store/n4dd49in4yx6xn5mda8pdf318qbn04p7-gcc-vc4-stage2
<clever> chessai: oh, i recently found a great boot info script
<clever> only if nixos is managing your bios firmware, would that be a risk
<clever> though the tests arent that extensive, and such a thing might still slip thru
<clever> it could be a kernel bug that corrupts your FS
<clever> depends on what the issue is
<clever> that exposed a lot of people running from the wrong channel, as updating bricked things
<clever> nixpkgs-unstable updated, nixos-unstable didnt
<clever> evils: about a year ago, a bug appeared in grub, that broke booting entirely
<clever> evils: nixos-unstable runs extra tests, to make sure the channel wont brick a nixos machine
<clever> evils: you should never build nixos from the nixpkgs- channels
<clever> ive always uses nixos-unstable
<clever> evils: the irony, is that you exit both with :q, lol
<clever> evils: i once saw somebody in this channel, asking how to quit `nix repl` and saying it was as difficult as vim!
<clever> evils:
<clever> infinisil++
<clever> infinisil: ahhh!
<clever> uhhh, what? lol

2019-10-19

<clever> Shouou: you may still pay that, to install pkgs.electron, but at least you have the chance to share it between other electron-y things
<clever> Shouou: and now the package is slightly smaller, and can benefit from security updates to pkgs.electron!
<clever> evils: that happens randomly if nix-daemon was stopped
<clever> though i had no encrypted datasets
<clever> evils: ah, thats pretty similar to the testing i did
<clever> so its near imposible to debug when it stops working, lol
<clever> but while it does boot, all directory listing operations fail
<clever> evils: i have gotten grub to boot from zfs, without encryption
<clever> evils: that would require grub to support the encryption, which i dont think it does
<clever> evils: biggest detail is if /boot is on zfs or ext4
<clever> evils: yeah, it also depends heavily on how complex the tests are
<clever> part of why nix just defaults to not testing things
<clever> evils: yeah, you kind of need to know how the tests work and how to make them pass, and what they are doing, to get things fully working
<clever> hpfr[m]: you could try to make the override only apply to xorg, or you could PR the fix to nixpkgs, so hydra.nixos.org builds things for you
<clever> hpfr[m]: checked the same thing, and its not a direct dep, but it may be an indirect dep (via something else)
<clever> hpfr[m]: wacom is probably doing it, if you temporarily comment out wacom, what happens?
<clever> hpfr[m]: any overrides that modify qt?
<clever> hpfr[m]: are you sure the binary cache is enabled?
<clever> hpfr[m]: all of those k things depend on qt directly, the bigger question is why qt differs
<clever> hpfr[m]: is the machine set to use kde/plasma?
<clever> evils: :q!
<clever> Shouou: before the nodejs could compile in nix, this package was just extracting the js from a darwin installer, then running a linux electron against it
<clever> Shouou: and skip trying to build the js itself
<clever> Shouou: you can just grab the asar file (after patching) and run the nixpkgs electron on it
<clever> evils: `installCheckTarget = "check";`
<clever> evils: ah, you need to tweak it to run the other `make check`
<clever> Shouou: what happens if you run the nixpkgs electron instead of copying the electron that came with etcher?
<clever> and what to wrap
<clever> pie__: you have to tell it what to prefix
<clever> pie__: wrapProgram if they depend on another binary, or bake the path into the code before you compile
<clever> pie__: or wrapProgram
<clever> pie__: installPhase = "cp ./foo $out/bin/foo";