<clever>
boomshroom: the other just renames the program to .foo-wrapped, and then calls the 1st
<clever>
boomshroom: there is both makeWrapper and wrapProgram, i can never remember which is which, but one takes a pair of source and destination, so destination becomes a bash script that runs source
<clever>
nope
<clever>
tilpner: you just need to be carefull when the foreign binary is something ldd can be ran on
<clever>
thats using a dynamic bash, so ldd returns bash's deps, not the foreign binary deps, but in java's case, ldd doesnt make sense
<clever>
tilpner: the writeShellScriptBin in your paste
<clever>
and suddenlllllllly, you have x86 libraries in your arm initrd!
<clever>
then the x86 ld.so parses those magic vars, and dumps qemu's deps!!
<clever>
binfmt-misc then runs qemu against that ld.so
<clever>
tilpner: ldd just sets some magic variables, and runs the local ld.so against the file in question
<clever>
tilpner: you must also avoid dynamically linked binaries if your emulating another platform, due to how ldd works
<clever>
hmmm, now to wrangle some c++ types!
<clever>
src/libstore/derivations.cc:59:36: error: conversion from 'nix::Setting<std::__cxx11::list<std::__cxx11::basic_string<char> > >' to non-scalar type 'nix::StringSet {aka std::set<std::__cxx11::basic_string<char> >}' requested
<clever>
yeah
<clever>
tilpner: boot.binfmtMiscRegistrations didnt exist when i wrote that
<clever>
it looks like the Settings class has been entirely rewritten since i made this patch
<clever>
boomshroom: nope, thats built into the kernel
<clever>
hmmm
<clever>
src/libstore/derivations.cc:59:62: error: 'class nix::Settings' has no member named 'get'; did you mean 'set'?
<clever>
but nixos now has a boot.binfmtMiscRegistrations to handle things for you
<clever>
boomshroom: line 31-40 generates a bash script to configure it
<clever>
tfc[m]: interactive and non-interactive shells source different files
<clever>
tfc[m]: i think you need to add the nix logic to .bashrc
<clever>
tfc[m]: what OS is the remote machine?
<clever>
boomshroom: ive also used it to refer to files within nixpkgs in a pure manner, tarball = pkgs.callPackage (pkgs.path + "/nixos/lib/make-system-tarball.nix") {
<clever>
boomshroom: so you could import (pkgs.path) { new config };
<clever>
boomshroom: pkgs.path is the path the pkgs set came from
<clever>
tfc[m]: `strace -ff -o logfiles -e execve nix copy --to ...` can you gist the logfiles this generates?
<clever>
tfc[m]: and it works when you just `ssh bla` ?
<clever>
tfc[m]: and yeah, id also consider that a bug in nix, an issue should be filed
<clever>
tfc[m]: https://gist.github.com/cleverca22/07dc4f902b5f6d998965887ff861f406 for example, line 1 is what it matches on from the cli (ssh example.com), then line 2 overwrites the host it actually connects to (optional, but handy for aliases), and line 3 changes the default username
<clever>
tfc[m]: you can specify a default username in ~/.ssh/config
<clever>
nixpkgs.config sets the config arg, but crossSystem is a sibling of config, not a child
<clever>
which gives me an idea...
<clever>
and it will farm it out to a machine that can run the right toolchain
<clever>
boomshroom: i'm not sure how to set the arch for nixos cross, but for nixos native, you can just do nixpkgs.system = "i686-linux"; for example
<clever>
boomshroom: for native or cross compiling?
<clever>
boomshroom: the nixos side of things works on pretty much any arch linux supports, natively and cross, the issue is more about building the nixpkgs side of things
<clever>
they insist on natively built things
<clever>
and tools like nix-env dont play nicely with cross-compiling currently
<clever>
native compiling is simpler, but it can also be cross-compiled with some effort
<clever>
boomshroom: it also runs on 32bit x86, 32bit arm, and 64bit arm
<clever>
the above opens the default.nix for the hello package in $EDITOR
<clever>
try: nix edit -f '<nixpkgs>' hello
<clever>
nix edit has been handy
<clever>
i havent looked into how 2.0 works in depth yet
<clever>
but nix-env is the only tool to ever use this layout, so its rather useless the instant you want to just build or shell
<clever>
the only purpose for channels vs channels_root, is that only root can write to the channels_root directory, so each user can maintain control over their group of channels, but can also share with others
<clever>
and it has no depth limit, so ~/.nix-defexpr/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/default.nix becomes a channel called z!
<clever>
if a directory contains a default.nix, it wont be recursed into
<clever>
in both cases, the <name> becomes what you refer to it as in nix-env
<clever>
it accepts both <name>.nix and <name>/default.nix
<clever>
depends on if you want to store a collection of channel-like things or not, and if they have any files they also need
<clever>
infinisil: yep
<clever>
nix.nixPath i think it was
<clever>
you can also set it in configuration.nix
<clever>
electroc1t: <nixos> and <nixpkgs> map to the same path by default
<clever>
electroc1t: thats the nixos channel on root, which has a nixpkgs symlink to .
<clever>
tilpner: but your calling it with {} already, so it cant
<clever>
tilpner: when you use nix-env --arg config '{allowUnfree = true;}' it will pass it to the function it loaded
<clever>
though that breaks nix-env -iA nixpkgs.hello --arg config ...
<clever>
nix-env expects it to return a function
<clever>
tilpner: i think you need to drop the {}
<clever>
tilpner: this creates a foo channel, so i can nix-env -iA foo.hello
<clever>
foldingcookie: and once it has done that, it has to check every .narinfo file on cache.nixos.org for the outputs your missing, to figure out what it can download
<clever>
foldingcookie: it has to evaluate every package in nixpkgs, which requires reading all the default.nix files, and running all the expressions, on your machine
<clever>
!-A
<clever>
which may be handy for more complex things when you cant just copy/paste the whole command
<clever>
nh2[m]: though .overrideDerivation can modify it, the way you linked
<clever>
nh2[m]: no real difference
<clever>
mguex: and then opening a unix socket inside the sandbox, and forwarding things both ways, along the nix protocol
<clever>
mguex: there will need to be support for multiple bi-directional channels, similar to how the stdout is forwarded to the client
<clever>
robstr_: strange
<clever>
robstr_: nothing at all?
<clever>
robstr_: does dmesg say anything?
<clever>
nh2[m]: yeah, that should work
<clever>
nh2[m]: i dont think there is, but you can use something like the wrapped i gave, to just make a symlink at any path pointing to any path
<clever>
infinisil: and each item is installed as a seperate entry, so i can still update just one
<clever>
infinisil: i find that handy, i have a custom set of packages in my overrides, and i just nix-env -iA nixos.mystuff which is a set
<clever>
infinisil: ive used it recently, and have even written a weechat service for nixos, but i still use irssi as my primary client
<clever>
robstr: if you already navigate irc with commands, it should be easy, its just /join, /part, /connect, /server stuff
<clever>
robstr: i use irssi, its curses based
<clever>
ah yeah
<clever>
yegor]: ah, if your in a shellHook you can just use $(pwd)
<clever>
yegor]: what do you plan to do with that path?
<clever>
yegor]: why do you need the working directory?
<clever>
ahhh, right
<clever>
yegor]: builtins.toString ./.
<clever>
and with the sheer size, you have even less reason to share a nibble
<clever>
LnL: for ipv6, you flip it backwards, and each nibble (4 bits) is a segment, less need to share a dns server
<clever>
LnL: for ipv4, you flip the ip backwards, and each byte is a seperate segment, so you have to delegate the "subdomains" and if 2 people share a byte, somebody has to store both sets of answers
<clever>
electroc1t: not directly, the file on 20-28 isnt expandable, but you can use services.xserver.displayManager.sessionCommands = "${xorg.xrdb}/bin/xrdb -merge ${./yourfile}"; to just inject more things in
<clever>
roconnor: undefined reference is a link-time failure, you need to pass -lsodium to the linker
<clever>
tobiasBora: not sure yet, still testing things
<clever>
roconnor: no, the stdenv handles that
<clever>
tobiasBora: with NIX_REMOTE=local?root, it basicaly fakes a chroot, during the nix build, so the build expects that path to become / at runtime, requiring proot
<clever>
roconnor: libsodium, the stdenv handles the rest for you
<clever>
the NIX_REMOTE one still needs proot to function
<clever>
also, https://nixos.org/nix/install doesnt really need root, if the admin simply does `mkdir /nix && chown tobias /nix`, you can install with zero sudo access
<clever>
proot or namespaces get around that issue
<clever>
so every user has to have their own custom build
<clever>
and it wont work in /home/tobias/nix
<clever>
the problem there, is that the compile only works in /home/clever/nix