Our roon server package for NixOS tries to download roon from the following URL: https://download.roonlabs.com/updates/stable/RoonServer_linuxx64_${version}.tar.bz2, where ${version} is replaced by the current version, which previously was 100700571.
When I try and download build 610, and thus version 100700610 the file isn’t there:
$ curl --show-error --fail -O https://download.roonlabs.com/updates/stable/RoonServer_linuxx64_100700610.tar.bz2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found
it’d be nice if the download mirror was update to have the latest release build.
Sorry for the delay. I checked with our team, and it doesn’t look like that’s an up-to-date URL. Can you try using the URL from our Linux easy-install script and let us know if that works?
The URL used in that script is http://download.roonlabs.com/builds/RoonServer_linuxx64.tar.bz2. The issue there is that it is not versioned, and so when the next Roon release comes and the hash for the file changes the package will be broken, which isn’t great.
The nice thing about the old URL is that it provided a _static_address for a given release, as opposed to one where the file is changing all the time.
Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
N/A
Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
N/A
Description Of Issue
Hi,
I currently maintain the Roon server package for Nix/NixOS, one of many Linux distributions. In Nix, much like in other packaging systems, sources that get fetched to build packages (like Roon’s binaries) are verified with a hash, to ensure authenticity and validity.
Currently, however, Roon clobbers their .tar.bz2 release file with every update. Meaning every time a new version of Roon is released the hash changes and the package stops building. This is true not only for Nix but for any packaging system that bothers to check the source hashes. This, in practice, means that it’s currently impossible to package Roon for Linux. Every time there’s an upstream release all packages break and someone has to go and fix all the hashes and wait until it happens again.
I’d like to ask that the releases be made available in some way where their are not clobbered, for example by adding the version to the file name, and so that the availability of a new release does not immediately break existing packages.
Yeah, this is super frustrating. Especially given that the solution is relatively simple; just add the version to the file name so that when new ones are released the old ones aren’t clobbered.
@dylan Is there any chance we can get some feedback from the team? As a paying customer, having to wait 6 months for some answer/resolution isn’t great.
How do you build packages for NixOS? Are you essentially curl'ing down the binary from Roon Labs and then re-distributing it? If so, I don’t think Roon Lab’s copyright allows for that. When the end user types nix-env -iA nixos.roon-server, this should result in a download from download.roonlabs.com to their system.
There is no redistribution happening, as I believed that would violate the terms of Roon’s license. Admittedly I did not bother actually checking that, but better to be safe than sorry.
The package is marked as unfree in Nix, which means it is not built or cached by Hydra, so when a user attempts to evaluate the derivation, the Nix build kicks in and fetches the package source (the binary tarball) and packages it locally. You can read the package derivation, which I maintain, here: nixpkgs/default.nix at master · NixOS/nixpkgs · GitHub
So, to answer the question concretely, end users are downloading from roonlabs.com directly when evaluating the roon-server derivation. This is why the unstable download link is especially bad, as it means a new user of roon might have their build fail (since the link changed the tarball it downloads) while an old user might not notice anything at all (since they have the package cached locally).
Our current “solution” is to use the web.archive.org cache to download specific snapshots of what the tarball link points to. It’s hacky, annoying, and we’re not even clear whether those web.archive.org snapshots are themselves correctly licesed/copyrighted.
Hope this clarifies things!
P.S. Users should virtually never use nix-env and opt for nix-shell for imperative package usage. If you want something permanently available on your system, do it declaratively via home-manager or configuration.nix. There is a roon-server module which I also maintain.
Interesting. It seems that your local packaging process is incompatible with Roon’s distribution process (which they get to define as owners of their code). On line 14, you hard-code the version:
version = "100700710";
As you pointed out, you also hardcode the SHA256 hash, which is guaranteed to be unstable over time.
I wonder if you can evaluate these dynamically.
Using archive.org is worse than a hack; I’m not an attorney, but it also seems to violate Roon’s copyright.
Roon Labs only support one version (build) at a time, so I don’t think it’s reasonable to expect them to make past builds available. It’s fair for you to ask for an accommodation, but it’s also fair for Roon Labs to dictate terms of software distribution and insist that you adapt to meet their terms if you wish to include their software in NixOS’s packaging system.
Yes, the point of a version and hash is that they are “hardcoded” with regards to a given package derivation as-written. This is not unique to Nix, and other distributions do the same. It is incredibly irresponsible to download something off the internet, not verify its hash against a known-good one, and then install it on your computer.
What is even the point of evaluating a hash dynamically? The whole reason it’s there is to allow users to be sure they are downloading and installing the thing that was packaged, and that upstream didn’t replace the binary (via a new version or via some hack, etc.)
Yes, this is exactly what this request is about. Although more than about my “local packaging process” it’s about how Linux packaging in general works. I’m not aware of a Linux package manager worth its weight that doesn’t rely on the package source being verified in some way. The complaint here is precisely that Roon’s distribution process makes safe, sane, packaging of their software incredibly hard.
That’s archive.org’s problem. We started using that mirror because another user hit the issue of the hash changing from under them and breaking the package, so they changed it to the mirror.
I never asked for that. If they want to yank older releases and make them 404 that’s still better than the current scenario where the URL just changes to point to something else all of a sudden.
Sure, but that hasn’t happened either, it’s mostly been radio silence. I wouldn’t be here pressing on this if someone from Roon had come and said “We do not care about you as a user, and will not be providing support for this.”
I think I would just write a few lines of Ansible that check to see if Roon (Bridge or Server) is already installed. If not, curl down the appropriate Bash script and run it. If so, just trust that Bridge/Server will update themselves automagically over time.
Hmmm…that’s just how Roon works, as far as I understand. If that’s not possible, Nix/OS is not a great platform upon which to run Roon Bridge/Server. Arch Linux, Fedora Server, or Ubuntu Server are likely better targets as they do not have similar hangups.