<clever>
ive only seen it copy when using a symlink to the store
<clever>
since its already immutable
<clever>
if the item is already in the store, it wont copy it
<clever>
ocharles: and no toString on that value?
<clever>
ocharles: the key is --arg, not --argstr
<clever>
ocharles: if the ghc is already in the nix store, it will just use it, and it already has deps
<clever>
ocharles: you could just pass it the path to a ghc, --arg ghc $(which ghc)
<clever>
only something that nix-build is building can have deps
<clever>
ocharles: nix-store --add cant deal with any dependencies
<clever>
ocharles: sounds like you just want to run `nix-build ghc.nix --arg file ./file.hs` basically
<clever>
ocharles: if you call builtins.derivation with the right args, it should create that
<clever>
that just tells it how to pretty-print the object
<clever>
yeah
<clever>
the other attrs are just misc data, that let you do other things with the object
<clever>
> let foo = { outPath = "bar"; }; in "${foo}"
<clever>
ocharles: if a set has an outPath and you try to treat it as a string, it just uses whatever the outPath is
<clever>
if you know which nixpkgs it came from, its much simpler
<clever>
ocharles: and then incrementally recreate the nix expression
<clever>
ocharles: you can use nix-diff to compare 2 .drv files
<clever>
siers: then generates a shell script that takes over the old binary name
<clever>
siers: it renames the binary to .binary-wrapped
<clever>
pie_: dig +trace, will explain it
<clever>
pie_: dig will obey /etc/resolv.conf by default, but it bypasses nscd
<clever>
pie_: dig
<clever>
your welcome
<clever>
i prefer having it in a $HOME, so i dont have to cd as far
<clever>
user preference again
<clever>
but its mostly user preference at that point
<clever>
pie_: thats why i keep it in /root/ instead
<clever>
inferencerules: then you dont need any symlinks, and that might have also fixed it
<clever>
inferencerules: what i would instead do, is create a /etc/nixos/configuration.nix, that has just 1 line: { imports = [ /home/clever/nixcfg/configuration.nix ]; }
<clever>
inferencerules: was it setup the exact same way before the upgrade failed?
<clever>
could be interesting to try and reproduce it
<clever>
inferencerules: any symlinks happen to be involved in that file?
<clever>
id expect builtins.genericClosure to detect that, but maybe symlinks are breaking it
<clever>
tobiasBora: and a quick skim over it says that the "biggest" thing your building is a single perl package, the rest are just configs
<clever>
tobiasBora: i dont see any kernel in that pastebin, only linux-modules (a buildEnv) and modules-shrunk (the closure used by the initrd)
<clever>
and due to hydra pre-building things, it wont have to compile anything
<clever>
tobiasBora: and only if that build is green, will i know that nixos-rebuild switch can pass without errors
<clever>
tobiasBora: personally, i have my own hydra setup, to build my entire nixos config, against the latest version of a channel
<clever>
pie_: ive played a bit with namespacing, and read over how nix creates a namespace with only lo, but i havent seen the code yet to create a linked pair of ve- IF's in seperate namespaces
<clever>
[root@router:~]# cat /proc/net/nf_conntrack | head
<clever>
the conntrack table handles that
<clever>
if your not doing NAT, then the reply could come down a different path
<clever>
so the router has to un-fudge it
<clever>
but, when the reply comes back, it will have the "wrong" destination
<clever>
so the router will fudge the source ip
<clever>
and in the case of 10.0.2.2 going to the web, you cant claim ownership of 10.0.0.0/8
<clever>
for the responce to make it back to you, the source ip you claim must also be in the routing tables
<clever>
each hop notices that the dest ip is "wrong", looks it up in its own routing tables, and relays it via the next gateway in the chain
<clever>
yeah
<clever>
the router also had NAT setup, so it will mutate the src ip along the way
<clever>
and forwards it in the right direction
<clever>
and because forwarding is enabled, the router looks that dest up, in its own routing tables
<clever>
the OS within the router, then notices the dest ip is "wrong"
<clever>
the dest mac is what triggers the remote NIC (in the router, in this case) to respond to the packet
<clever>
when your default route says `via 10.0.2.2`, then you lookup the mac of 10.0.2.2, then send things to the public ip (say 8.8.8.8) but the mac of 10.0.2.2
<clever>
you must use ARP to lookup the mac behind an ip
<clever>
on typical ethernet based networks (wifi and ethernet), you can only ever send packets to a mac, never an ip
<clever>
its likely showing up on lo
<clever>
pie_: its the same as sending to 127.0.0.1
<clever>
pie_: nope, linux will notice that that is its own ip, and not even shove it out the interface
<clever>
then it will route it to the guest, via whatever device the guest ip shows up on (routing tables again)
<clever>
it must point to the guest ip
<clever>
via points to 10.250.0.1, the host
<clever>
oh wait, theres the problem
<clever>
yep, that looks fine
<clever>
/12 is 8 + 4
<clever>
243 0xf3
<clever>
240 0xf0
<clever>
checking the numbers...
<clever>
pie_: what does `ip route` on the host say?
<clever>
pie_: what IP are you trying to ping?
<clever>
pie_: check the main interface of the host, do you see the ping there?
<clever>
pie_: there should be a virtual if between the host and container, and tcpdump should see it on both ends of that if
<clever>
pie_: and does the container see the ping on its internal IF?
<clever>
pie_: what are the IP's on the host and container side?
<clever>
pie_: so if your pings appear to come from 192.168.2.100, the remote machine will either send a responce out onto the lan (for nobody to hear) or out the main router (onto the general internet, for nobody to hear)
<clever>
pie_: the source ip matters
<clever>
`tcpdump -i IFACE -p -n icmp`
<clever>
tcpdump on every link, and a ping, will show you how far things are getting
<clever>
pie_: and setup a either NAT in the container, or a reverse route so the far end knows how to send replies back
<clever>
pie_: and enable forwarding within the container