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.
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 ^^
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.
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.
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 = “https://download.thimeo.com/stereo_tool_gui_64_${version}”;
hash = “sha256-ByRguhZ29ertQM3q+TPUUT1BMnAJGbwNe8WbNxLhcmk=”;
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
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
"1021"
Great job Just, a few remarks that you need to fix before commiting:
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 https://download.thimeo.com/stereo_tool_gui_1021
Downloaded 'https://download.thimeo.com/stereo_tool_gui_1021' 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 https://download.thimeo.com/stereo_tool_gui_jack_p2_1021
error: unable to download 'https://download.thimeo.com/stereo_tool_gui_jack_p2_1021': HTTP error 404
response body:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>
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.
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";
…
}
into:
{
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.
[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’