Change:
doCheck = false; /* wants network */ }; <ins> NetHTTPSNB = buildPerlPackage { pname = "Net-HTTPS-NB"; version = "0.15"; src = fetchurl { url = "mirror://cpan/authors/id/O/OL/OLEG/Net-HTTPS-NB-0.15.tar.gz"; sha256 = "0kwc4z8pqnbc396wjnlgdmri10zdh91f2bi6saxkpfjzlm7wysba"; }; propagatedBuildInputs = [ IOSocketSSL NetHTTP ]; meta = { homepage = "https://github.com/olegwtf/p5-Net-HTTPS-NB"; description = "Non-blocking HTTPS client"; license = with stdenv.lib.licenses; [ artistic1 gpl1Plus ]; }; }; </ins> NetIDNEncode = buildPerlModule { pname = "Net-IDN-Encode"; version = "2.500";

Discussion:
Describe the bug Similarly to , complains about missing as a dependency during startup. Bizarrely, IOSocketSSL seems to be in , though. ~I also didn't encounter the same issue when I tried deploying slimserver on my private NAS (an x64 machine) instead, which is why I'm guessing that this is somehow architecture related.~ Correction: The issue is version 7.9.2, which is packaged in , wich the raspbi image uses by default. The error message looks like the one below. Note that it appears even before the main init routine is executed. By inspecting in the nix store, I can see that the call in also seems to patch the main slimserver script with a path to IOSocketSSL: However, the generated shebang above contains the following path 5(!) times: Since I have no real experience with Perl, I'm not sure how to proceed. I tried writing my own custom bash wrapper that would override the or environment variables, but had no luck with that, either. To Reproduce Steps to reproduce the behavior: ~Set up NixOS for a Raspberry PI 4 using the indicated by the .~ Install v. 7.9.2 (from ) up (). startup, will log the error message mentioned above (visible in ) Expected behavior should behave the same way as on x64; i.e. the message should not appear during startup and the server should be able to install plugins (e.g. the Spotify plugin in my case). Plugins should also be able to include . Notify maintainers Metadata Maintainer information:
As an addendum: still seems to be able to limp along more or less without the library embedded (as the message above indicates, it just seems to try using unencrypted HTTP). While this is fine for e.g. internet radio, it seems to break the plugin downloader as well as the Spotify plugin, though.
I faintly recall that this error could also be caused by perl failing to load a C library. I think last time I found it using , but I dont' really remember.
Hi thanks for the hint! I've recently tried the following (in bash): could not reproduce the issue in this way. Is this behavior consistent with your theory?

( If I run the same code without the shebang from , I see the same error: )
As for the loading of libraries: I've just run the following: You can find the full output ('s the raw log output). What catches my eye is this: Does this mean that actually, is not able to see ? In order to test that out, I've tried the as mentioned above with the following code snippets: they all seem to work for me nonetheless. As I mentioned, I'm not really familiar with Perl, its ecosystem and its loading mechanisms, so I feel out of my depth here.
I just stumbled upon and thought, I'd try running it against the wrapped slimserver script. are the results (, again, is the raw log). I think I found the culprit. As far as I understand these two bits: It looks like fails, whereas succeeds. So, I looked for the in question and found : While the included version seems to be 2.068: What I don't understand, though, is how the same package is able to run just fine on my x64 machine. In any case, I'll try to replace the version requirement in this line with the version provided by nixpkgs. If it seems to work, I'll open a PR.
I discovered two more things: I still had a custom version of linked into my configuration (I had tried if the latest version (8.1.0) would fix this issue). If anyone is wondering why the lines above all reference this version: That's why. The issue is the same for 7.9.2, though. The CPAN file I linked to above is stripped from the repository, so that can't have been the reason. As another way to approach this, I'm currently trying to somehow discover the difference in my x64 box compared to the Raspberry Pi. Further looking at the code of slimserver, I discovered . From the way this code seems to work, I'm guessing that actually isn't the problem here -- the reason might simply be another error in .
I finally figured out why SSL seems to work on my x64 box as opposed to my Raspberry Pi 4: I hadn't realized that the raspi image uses . My NAS runs , which references an older version of -- 7.9.1 as opposed to 7.9.2.

From , I discovered that v7.9.2 is the version that introduced the I mentioned earlier. Along with that, was . My guess is that the issue is somehow related to those changes, but I still wasn't able to figure out how or why. However, since the initial issue text is based on a lot of wrong assumptions, I'll update that.
That looks like quite the journey you had ... I know that the CPAN stuff in slimserver was quite a bit annoying when initially packing slimserver. Today, we mostly use the libraries from nixpkgs itself and remove most dependencies from the bundled CPAN folder. Maybe some CPAN library in nixpkgs is too old and missing some modules?
Well, at least I'm learning a lot by tracking this down. Thanks for staying with me so far! :) I think I found a fix for this specific issue: AFAICT, the issue really boils down to introducing a new dependency to the (see the ), which is missing in the nixpkgs build. I've prepared where I introduced a new entry for said package and referenced it in . With these changes, the plugins setting tab seems to work properly on my Raspberry Pi. Before I start a PR for this branch, there still are a couple of details to consider: Is it okay to just introduce a new entry in ? Must there be someone who's willing to step in as a maintainer for the new entry w.r.t. nixpkgs? I found no license statement in the of Net::HTTPS::NB. CPAN states its license as . I'm not sure what I'd have to put into .
I think license should be just the same as perl itself: And adding a new entry in perl- should be okay, at least it's what I myself have done in the past. As far as I can see, a lot of the perl packages don't have maintainer entries, so maybe it's okay without? Not sure.
Okay, thank you very much! I'll update the branch and prepare a PR then. In other news, fixing this issue caused me to run head-first into the next one ;) I've opened a new issue for that one: