How to find needed librarys for closed source bin applications

Great! Then, maybe try to make sure the binaries are fetched correctly for others architectures, make sure your file is correctly indented, and do a first push on your fork. Show it to me, if it looks ok, you can submit the PR.

not sure to understand

Maybe i get an answer, if there are versioned releases…

I see only releases for Raspi 2-4… and 3/4 64bit…

64 bits & 32 bits, and raspberry pi 2-4 is in fact ARM 32 bits and ARM 64 bits. So it’s already 4 architectures, not that bad. There is also Mac OS, but let’s start simple ^^

That part has to be repeated for 32bit and one or two block for Raspi…

yes. That’s also why people prefer to package open source softwares :stuck_out_tongue: It’s a bit boring, but nothing impossible.

This name

name = “alsa”;

belongs to ?

install -Dm755 alsa $out/bin/stereo_tool_gui

So i have to use alsa32 alsarp2 alsarp4 ?? rp=Rapsi

The alsa in the install refers to the name instead, but do NOT use alsa32 etc… that’s the whole point of this construction: keep the exact same name for the fetchurl: alsa, cmd and jack, and you do not need to change the install phase at all. The download & unpack phase will put the appropriate binary in alsa/cmd/jack, this way the install phase do not need to worry about whether it is 32 bits/64 bits etc.

OK, and the desktopicon can refer to this name also…? :wink: I guess not…

desktopItems = [
(makeDesktopItem {
name = pname;
desktopName = “Stereotool-Gui”;
exec = “stereo_tool_gui_64”;
icon = “st-icon”;
comment = “Broadcast Audio Processing”;
categories = [ “AudioVideo” “Audio” “AudioVideoEditing” ];

No, you should just use the same executable name for all architectures in my opinion (the one already given by the install phase stereo_tool_gui, stereo_tool_gui_jack and stereo_tool_cmd), and just create your items with this name. You might just want to create two items, one for the jack version and one for the alsa version, just duplicate the entry in this list.

What if i run this a 2nd time? Should i delete the result dir before?

Btw. It needs some trail and error to find the right {} constellation… :wink: bec of.

error: attribute ‘desktopItems’ already defined at

Finaly this seems to work, but i cannot test it of course. But as u can see. I’m learning … slowly…

desktopItems = [
(makeDesktopItem {
name = pname;
desktopName = “Stereotool-Alsa”;
exec = “stereo_tool_gui”;
icon = “stereo-tool-icon”;
comment = “Broadcast Audio Processing”;
categories = [ “AudioVideo” “Audio” “AudioVideoEditing” ];
(makeDesktopItem {
name = pname;
desktopName = “Stereotool-Jack”;
exec = “stereo_tool_gui_jack”;
icon = “stereo-tool-icon”;
comment = “Broadcast Audio Processing”;
categories = [ “AudioVideo” “Audio” “AudioVideoEditing” ];

Sooo, added url from today… If u like take a look…

Missing the hashes… But its late now… good night

Hmm, The files ar throwing an 302… wft

Tried this morning again. With wget i get two times an 302 and the 200 OK for an older version from year 2022. For now i don’t know why…

Hi. I’m in contact with the stereotool maintainer, he has the files with numbering on his webservice, so it could go further the next days…

OK, this is the url.

That should work then. And i will try to set a variable like version=“1021” to not change for every release so many lines…

Mayby like this??

stdenv.mkDerivation rec {
pname = “stereotool”;
version = “1021”;
srcs = {
# For 64bits linux
x86_64-linux = [
# Source of the GUI version: we start from the alsa version
# Issue: the hash will change when they upgrade the software, not sure how to handle this
(fetchurl {
# The name is the name of this source in the build directory
name = “alsa”;
url = “${version}”;
hash = “sha256-ByRguhZ29ertQM3q+TPUUT1BMnAJGbwNe8WbNxLhcmk=”;

OK, the nix-built throws no error. Do you think i could make a commit??

Whats strange is, the results are dated at 1. jan 1970. Could i delete them to make sure that are the files from last run?? Obviously not, ro filesystem


No need nope.

Oh, great!

Very good idea. Just, maybe try to keep version to 10.21 since it is the real version (and nix does read this version) and derive another variable below, like:

nix-repl> version = "10.21"

nix-repl> versionNoPoint = builtins.replaceStrings ["."] [""] version

nix-repl> versionNoPoint

Great job :wink: Just, a few remarks that you need to fix before commiting:

  1. the hash you use is not the good one. You always use the exact same hash, while 32 bits and arm are obviously different. For instance:
$ nix store prefetch-file
Downloaded '' to '/nix/store/jh0fwy8bbzpdrky434771can6qjm6l0z-stereo_tool_gui_1021' (hash 'sha256-iEPqJvmXKXD4AVbM+1QZeUOwpMjMT7ROYNQpmhRVZyw=').

shows you the hash sha256-iEPqJvmXKXD4AVbM+1QZeUOwpMjMT7ROYNQpmhRVZyw= while you use sha256-ByRguhZ29ertQM3q+TPUUT1BMnAJGbwNe8WbNxLhcmk=. Similarly, some PATH give a 404 error (it is because you wrote _p2 instead of _pi2):

$ nix store prefetch-file
error: unable to download '': HTTP error 404

       response body:

       <title>404 Not Found</title>
       <h1>Not Found</h1>
       <p>The requested URL was not found on this server.</p>

Note that you do not get any error for 2 reasons: first, this file will only be downloaded for aarch32 systems, so since your computer is not aarch32, you never get the 404. Second, if it sees that the hash has already been downloaded in the past, it will not even try to re-download it (why would we bother re-downloading it?)… but if you update the url without updating the hash, then it will pick the older content since it is still in the cache.

  1. then, there is also a mistake with the desktop items: you forgot to add copyDesktopItems in the list of nativeBuildInputs. Basically, what this will do is add a shell hook to automatically copy the items listed in desktopItems = [ … ] to the share folder (see for details). Without this line, nothing will happen.

  2. the indentation is much better now. I can just spot a minor mistake in the line 109, done should be aligned with for, so remove two spaces before.

if you want to test it, you have different options. You can do it declaratively by adding it as a flake input to your /etc/nixos/flake.nix… but I would say it might be simpler to simply run, in the root folder of your copy of nixpkgs:

$ nix profile install ".#stereotool"
$ kbuildsycoca5 # update the entry cache of KDE, not sure if needed

I’m not 100% it works (apparently this should be fixed in recent nixpkgs, but I have a quite old version so I cannot test), so if it fails even after adding copyDesktopItems to your nativeBuildInputs, maybe try first with a well tested program, like alacritty to see if new desktop entries are listed.

Once these small issues are fixed, you can go with the commit! Just make sure to create two commits, one where you add you in the list of maintainers, and one where you add the changes as I explained earlier. Also, after the PR, you can cite me in the PR so that I can help with the review.

Thats what i add to the .nix file? No use of sed… Interesting.

That i have to do with every version and paste the hash??

yes, sunday afternoon… Not enough coffee at that time.

I would now be unsure whether it would disappear again. I still don’t have the skills to remove these test installations again.

I’m asking myself, how i can make an howto so i’m able to do these steps again. Ist the 2nd long thread. I know, you have written some howtos, but i’m not sure if that fits for this special case…

What I showed is just an interactive nix shell (useful to quickly try something) opened via nix repl. But in your case, just turn:

   pname = "yoursoftware";
   version = "1021";


   pname = "yoursoftware";
   version = "10.21";
   versionNoPoint = builtins.replaceStrings ["."] [""] version;
# replace version with versionNoPoint in your url below

Sed should not be used here because you have access to a bash shell only during the buildPhase etc… but downloading the source comes before. There is a way to make the input of a derivation dependent on the return of some arbitrary code… but this should be avoided as much as possible (this might be needed if your list of inputs is obtained via complicated mechanism involving an external package manager etc), so just use plain nix language for such simple tasks.

Yeah (if you have a single source code for all archs, you can simply set the hash to an empty value and get an error with the new hash… but here you have many sources so it is the simpler solution). It’s a bit annoying, but that’s how we preserve purity in nix for maximum reproducibility.

I can understand, if you prefer you can still use the declarative solution… but it is actually not too complicated to remove them:

$ nix profile list

will list everything installed manually.

$ nix profile remove N

to remove the N-th entry in the nix profile list (you will see they start with some numbers)

Well, it’s up to you ^^ You can either just create a local file (libreoffice or whatever) with the tutorial, or if you want to make it public you can create a new thread here in the “Guide” category.

No worries, the date is mostly configured this way to ensure better reproducibility, this way the output is mostly independent of the day you compiled the software.

Whats wrong?

[wolf@daw:~/git/nixpkgs]$ nix profile install “.#stereotool
error: flake ‘git+file:///home/wolf/git/nixpkgs’ does not provide attribute ‘packages.x86_64-linux.stereotool’, ‘legacyPackages.x86_64-linux.stereotool’ or ‘stereotool’