Package Details: reaper-bin 6.13-1

Git Clone URL: (read-only, click to copy)
Package Base: reaper-bin
Description: Digital Audio Workstation
Upstream URL:
Licenses: custom
Conflicts: reaper
Submitter: david0
Maintainer: david0
Last Packager: david0
Votes: 75
Popularity: 1.56
First Submitted: 2018-08-10 15:40
Last Updated: 2020-07-23 13:30

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 ... Next › Last »

jhernberg commented on 2018-08-10 16:36



david0 commented on 2018-08-10 15:42


It will be deleted soon.

jhernberg commented on 2018-08-08 12:53

@david0: Hi, I'm writing this as someone complained on the reaper forum about this package. Tried to email you, but haven't seen any response..

FWIW, I just discussed this with the boss (Justin), he had this to say: "should definitely download the main releases! the landoleet builds are not supposed to be linked to from anywhere (it says that on landoleet!)" and "also yeah it should use the official swell binaries".

My personal thoughts:

  1. Create a new package called reaper-bin following the AUR guidelines to indicate that it's a package that installs something binary instead of building a package from source.

  2. Do not build SWELL, AFAIK the one shipped in the tarball is working perfectly fine on Archlinux.

  3. Do use the desktop support in the tarball as that is more recent and has better functionality than the one I wrote ages ago which you are still using.

  4. Please use the script included in the tarball to install reaper, it was made for that. I'd recommend to run "sh --install "/opt" --quiet --integrate-desktop", which will install reaper into /opt/REAPER and add the needed desktop support.

  5. Then you only have to create the symlink /usr/bin/reaper -> /opt/REAPER/reaper and create one for the license.

Any user wanting to use the LoL version can download it manually as Windows & OS/X users do.

Also if you don't change this package there is a high possibility that Cockos will block downloads from LoL for scripts like this, that would IMO be a very sad occurrence..

Thanks in advance for your understanding :)

aggraef commented on 2018-08-04 11:41

@cogwerkz, you're right. Well, at least it's on the official download page now. :)

@david0, the sha256 changed once again, it's 1f7daf933f5d246239f803a113cf0407357df7597b00cc135d8e05c845c0e599 now, so I guess that a new version is out already. Looks like the versions on Landoleet and in the official Reaper downloads are the same right now.

I guess I'm inclined to agree with pha-qu that the official Reaper downloads are the way to go. However, it's debatable whether putting a link in a shell script for convenience would count as a "link". After all, the PKGBUILD doesn't do anything that a user couldn't do manually. And the PKGBUILD certainly doesn't redistribute the tarballs, so we should be good there IMHO.

The fact that the tarballs keep changing all the time is really unfortunate. Well, I guess the only way to deal with this (apart from setting up a script which does automatic monitoring and updating the PKGBUILD every time the sha changes, which will not really be that secure either) is to flag the package as out of date as soon as anyone encounters this. Or maybe just accept the fact that the tarball keep changing all the time and use SKIP on it, like with a git repo.

pha-qu commented on 2018-08-03 20:53

I have a question, the PKGBUILD file still points to landoleet which carries the bellow message: 1. DO NOT REDISTRIBUTE ANYTHING FROM THIS WEBSITE 2. USE VERSIONS FROM HERE WITH CAUTION AND AT YOUR OWN RISK 3. DO NOT LINK TO THIS WEB SITE OR ANYTHING ON IT FROM ANYWHERE 4. PLEASE DISCUSS ONLY IN THE PRE-RELEASE FORUM The reaper website bundles the latest files for x86_64 distribution at this url: Shouldn't the PKGBUILD respect the above request from landoleet, I notice the tar from is near identical to the one from landoleet beside some of the problems with the frequency of the files being changed rendering sha-pgp checks invalid if you don'y update as soon as possible? Comments welcome

cogwerkz commented on 2018-08-01 15:09

@aggraef The version itself is a release candidate, but the whole linux port is considered experimental, so it's probably fitting to still have that warning there. It's even noted by cockos on the reaper download page:

"Note: Linux builds are experimental and unsupported. Please read the included readme.txt for more information."

aggraef commented on 2018-08-01 13:31

Also, I think that the warning about this being an unsupported experimental version can (and should be) removed now; AFAICT this is an official release candidate.

aggraef commented on 2018-08-01 13:28

@david0, I think that your intent here was to create both reaper and reaper5 links pointing to the reaper binary in /usr/lib/REAPER? But the second ln command is wrong. It should read:

ln -s /usr/lib/REAPER/reaper "${pkgdir}/usr/bin/reaper5"

Also, to make the existing desktop files work you need, in addition:

ln -s /usr/lib/REAPER/reaper "${pkgdir}/usr/lib/REAPER/reaper5"

Obviously, this all gets a bit messy, but it works (see

Anyway, I'd suggest to follow @jhernberg's advice and see whether the --integrate-desktop option does the job, as far as the desktop files are concerned. Whether the application ends up under /usr/lib or /opt is a matter of taste; /opt sounds reasonable to me. Concerning the proper location for the symbolic link to the binary, however, I'd advise against a symbolic link under /usr/local/bin, it should go into /usr/bin -- /usr/local should be reserved for stuff the user installs locally and not be touched by packages IMHO.

jhernberg commented on 2018-08-01 11:10

Note that since a while reaper has it's own installation script taking care of most things. Something like "sh --install "/opt" --quiet --integrate-desktop --usr-local-bin-symlink" ought to take care of most everything.

We decided that installing reaper into /opt/REAPER and creating a symlink in /usr/local/bin was the best way to go. The installation script also takes care of the desktop/mime support and actually does it better than then old files I wrote which are used by this script.

Also note that the executable has recently been renamed from reaper5 to reaper.

I also question the need to separately build AFAIK the one included in the reaper tarball works perfectly fine on Archlinux.

Finally shouldn't this script really be caller reaper-bin?

capoeira commented on 2018-08-01 10:26

wait. isn't the problem of the PKGBUILD that it tries to create /usr/bin/reaper twice? have you tried removing only the second ln line @pha-qu?

what is the sense of the second ln line anyways? /usr/lib/REAPER/reaper5 doesn't exist