<clever>
hodapp: ah, so the source is just that big, even after removing .git
<clever>
hodapp: after you enter that nix-shell, what does this command say at the end?, du -h $src
<clever>
gchristensen: an rpi3 would have build-extra-platforms = armv6l-linux armv7l-linux aarch64-linux, while your thunderx's would just lack build-extra-platforms entirely (defaulting to the arch nix was built for)
<clever>
gchristensen: so you can describe that to nix-daemon correctly
<clever>
hodapp: then shell.nix will override default, and null out the src
<clever>
hodapp: you could make a default.nix that works with nix-build, then shell.nix would just be this: (import ./default.nix {}).overrideDerivation (old: { src = null; })
<clever>
ericnoan: that reminds me, i need to get firefox 53 on my nixos, so i can update my extension
<clever>
though i tend to keep src=, so i can also test with nix-build
<clever>
unpackPhase is what gives the error about missing $src, and if you never run it, it wont fail
<clever>
but you can omit src entirely
<clever>
you still need to use stdenv.mkDerivation to get a compiler and make buildInputs function correctly
<clever>
hodapp: you can also do src = lib.cleanSource ./.;
<clever>
hodapp: its probably trying to snapshot the entire .git folder
<clever>
hodapp: "warning: dumping very large path (> 256 MiB); this may run out of memory" is because the src = ./.; referenced over 256mb of files
<clever>
more like 6 hours later, lol
<clever>
hodapp: thats how i do things
<clever>
and rm -rf is far easyer then implenting a perfect make clean
<clever>
then the build dir isnt part of the source, so it cant mess up
<clever>
oh, and since its cmake, you also have the option to mkdir ../foo-build; cd ../foo-build; cmake ../foo/
<clever>
just remember to make clean, or the next nix-build will reuse the old .o's and make a mess
<clever>
but if your using nix-shell, you can just skip the unpackPhase and directly configure the source you have checked out
<clever>
each time you nix-(shell|build), the src = ./.; will copy a snapshot of the source to /nix/store
<clever>
all that will do is copy the source from the nix store back to the current directory
<clever>
unpackPhase is optional
<clever>
and you can just change the src in each of those nearby files to src = ./.; to make it always use the current source
<clever>
hodapp: this default.nix will return an attrset containing many derivations, and it will use callPackage to load each of them from other nearby files
<clever>
that would also explain it not working under nginx
<clever>
neat, the cpu will basicaly lie about pages existing, so there is no way to tell the difference between unmaped ram, and "secure" ram
<clever>
and qemu implements it as a seperate address space, more like a harvard architecture
<clever>
gchristensen: ah, it sounds like the arm has an extra bit on the address bus, to signal secure/non-secure
<clever>
'This additional address bit gives a physical address space for the Secure world and a completely separate physical address space for the Normal world.'
<clever>
nor would you need to be aware of the partitioning when configuring paging
<clever>
gchristensen: it almost sounds like the hardware has 2 different views of 'physical addressing', so you cant even bypass things with paging tables
<clever>
gchristensen: reading the arm docs more, it looks like trustzone is implemented in EL3, and going by the qemu source, that has its own address space that it lives in
<clever>
i think nginx will pass it on if you dont explicitely configure auth in nginx
<clever>
so nginx will allow/deny based on auth, but radicale wont even know auth is in-use
<clever>
but radicale wont know what user you auth against
<clever>
websocket and raw tcp are not allowed, but websocket can be added
<clever>
but it can only pass http traffic
<clever>
infinisil: when nginx gets a request on port 80 with the Host: header set to dav.infinisil.io, it will internaly relay the request to http://127.0.0.1:5234
<clever>
the firewall isnt allowing 5234 for remote access
<clever>
infinisil: let me throw together an example
<clever>
infinisil: ive found the nginx stuff in nixos to be great
<clever>
infinisil: ive done similiar for some servers i'm setting up, and ive written testcases that can spin up a fresh vm purely from the config, and run tests against the software
<clever>
infinisil: https://pastebin.com/9M2jiHmp this gets loaded by configuration.nix, and embeds my vimrc into the vim package, while also providing some defaults for env variables (line 37-40)
<clever>
infinisil: depends on if the package allows it or not, some things like vim and emacs let you embed the user config into the package
<clever>
infinisil: then i can just nix-env -iA nixos.mystuff, and it will atomicly update the profile to match the current config
<clever>
infinisil: it loads some custom packages, then defines a custom package called 'mystuff' that is the result of merging many packages
<clever>
Guest8704: and your fighting nickserv some
<clever>
Guest43251: nix-shell -p openssl
<clever>
tjg1: ah, that could be an issue
<clever>
avn: if we symlink /swap to /dev/zvol/tank/swap, then the stage-1 scripts will think its a swap file, and ignore it, but stage-2 will follow the symlink and use the zvol
<clever>
avn: it thinks the hibernation image is on that swap, and wants to resume it before mounting too much
<clever>
avn: hence the symlink to a zvol
<clever>
tjg1: but once you boot, it follows the symlink and uses the zvol!
<clever>
tjg1: then the safety on line 209 of stage-1.nix will think your using a swap file
<clever>
tjg1: what if you make a /swap symlink to /dev/pool/swap
<clever>
tjg1: oh, i just had a thought
<clever>
that also works
<clever>
tjg1: if you dont mind reinstalling, it might be better to change the layout to be more like my laptop
<clever>
tjg1: setting randomEncryption on the swap device might solve the problem your having, but then it will be double-encrypted
<clever>
i was expecting zvol swap issues, and used lvm to avoid them
<clever>
in my laptop, it is
<clever>
so a single passphrase protects the entire lvm array (swap + zfs)
<clever>
CMCDragonkai: the swap is on lvm, and the PV for lvm is on luks
<clever>
with the negative that the swap can be recovered if you have the passphrase
<clever>
so i would expect the swap->lvm->luks to have the same performance as swap on randomized luks
<clever>
i wouldnt expect lvm to add much overhead
<clever>
CMCDragonkai: the machine is nearly a decade old, so its hard to tell
<clever>
CMCDragonkai: i went with zfs+swap on lvm, with the lvm on luks, just to avoid the zvol swap issue
<clever>
tjg1: it must start with /dev, it must not have randomEncryption, and it must not be a zram
<clever>
tjg1: the s variant is the result of running a map and filter over the swap devices
<clever>
tjg1: it wants to load the hibernation state from the swap, and ive heard something about hibernation on zvol not working either
<clever>
tjg1: ah, i suspected it, its waiting for the resumeDevice
<clever>
gchristensen: this answer says how to enable secure mode, so lets just invert it, -machine secure=off -machine virtualization=off, this should remove EL3 and EL2 support
<clever>
ok, ive confirmed that it is an aarch64 qemu, built against aarch64
<clever>
this kind of mess is also why i was looking into UML linux for the nixos test framework, it seemed simpler then fixing qemu
<clever>
from what ive read, you can make a kernel that has a range of drivers linked in, and pass it a DTB that describes what hardware is actualy present, and which drivers to point at what addresses
<clever>
as will device-tree
<clever>
the bootloader like u-boot can help to even that out some
<clever>
and the boot process and hardware layout is far less standardized on arm, so the kernel is tightly coupled to how you make it boot, and what qemu has to emulate