Change:
<del> { lib, stdenv, fetchurl, unzip }: </del> <ins> { lib, stdenv, fetchFromGitHub }: </ins> stdenv.mkDerivation rec { pname = "libb64"; <del> version = "1.2"; </del> <ins> version = "2.0.0.1"; </ins> <del> src = fetchurl { url = "http://download.draios.com/dependencies/libb64-1.2.src.zip"; sha256 = "1lxzi6v10qsl2r6633dx0zwqyvy0j19nmwclfd0d7qybqmhqsg9l"; </del> <ins> src = fetchFromGitHub { owner = "libb64"; repo = "libb64"; rev = "v${version}"; sha256 = "sha256-9loDftr769qnIi00MueO86kjha2EiG9pnCLogp0Iq3c="; </ins> }; <del> nativeBuildInputs = [ unzip ]; </del> installPhase = '' mkdir -p $out $out/lib $out/bin $out/include cp -r include/* $out/include/

Discussion:
This is a regression from / (cc It breaks fairly basic functionality: if running a transmission-daemon on ARMv8, torrents cannot be using transmission-remote. Adding torrents by URL or by torrent upload via the web interface or using transmission-remote from before works (both daemon + remote needs to be past ). I have extensive debugging notes below, but I believe it's basically caused by latent bugs and hacks in libb64 that used to cancel each other and don't anymore now that we've switched to a systemwide v1.2 build. Steps to reproduce the behavior: a transmission daemon with on an ARMv8 host. to transmission-remote -a foo.torrent, where transmission-remote is built with . the server reporting an error: The torrent gets properly remote-. I spent my night debugging this and it's such a weird issue that really I'm just filing this bug report to document the fact that computers were a mistake and everything is broken. TL;DR: we need to bump libb64 to something less antique than 1.2. Apparently, libb64 which is used by Transmission to encode/decode base64 (which is how .torrent files are sent over the JSON-RPC interface) has a bug which causes it to not properly roundtrip on ARMv8. I discovered this by taking some simple example code for libb64 and running it on my ARMv8 host: (Note: this same roundtrip test passes on amd64.) Now, if all b64 decodes were broken it's likely someone would have noticed (transmission-daemon would be broken in many different ways, including the auth token for the RPC layer not being properly decode-able). It turns out that the roundtrip issue on ARMv8 is caused by having "invalid" characters in the base64 input. libb64 1.2 should normally be ignoring these spurious invalid characters. On ARMv8, it fails to do so properly. But, as it turns out, libb64 also consistently generates base64 encodings that include spurious characters: it adds a every 72 chars in the b64 output, as well as a final at the end of the encoding. We can actually verify that without the spurious libb64 manages to decode payloads, and transmission accepts our remote torrent submission: Ok, so the n are the problem.

Why did break this though? Is NixOS shipping an older version of libb64 than Transmission bundles? Turns out, no, not really. But for some unfathomable reason, the libb64 copy vendored with Transmission contains a patch which stops the encoding side of things from adding the that break the decoder on ARMv8: . ! I suspect this is entirely accidental and not at all related to the issue I've uncovered here, someone might have just tried to save some network bytes... but they ended up hiding this bug by pure luck. un-vendored libb64 by providing a system-wide alternative. This ended up removing the vendored patch which strips from the encoding. In turn, this triggered the latent ARMv8-specific bug in libb64 1.2 caused by the in the base64 encoded string. Breaking my torrent uploads with transmission-remote. Now, as it turns out, it looks like there is a semi-maintained fork of libb64 on GitHub: . According to repology, nobody major except Gentoo has switched to this upstream. But it includes some interesting patches like which claims to be "adding ARM compatibility", and which I've confirmed fixes the roundtrip problem with . I suspect the correct solution to this whole mess is to just upgrade nixpkgs libb64 to v2.0.0.1 on that new upstream. cc for transmission, and nobody for libb64 because of course it has no maintainer in nixpkgs :-) Maintainer information: