Package Details: reaper-bin 5.963-1

Git Clone URL: https://aur.archlinux.org/reaper-bin.git (read-only)
Package Base: reaper-bin
Description: Digital Audio Workstation
Upstream URL: http://www.reaper.fm
Licenses: custom
Conflicts: reaper
Submitter: david0
Maintainer: david0
Last Packager: david0
Votes: 52
Popularity: 2.562322
First Submitted: 2018-08-10 15:40
Last Updated: 2018-11-28 14:00

Latest Comments

1 2 3 4 5 6 ... Next › Last »

yan12125 commented on 2018-09-11 06:25

Done package movement - I merge reaper into reaper-bin instead of deleting reaper to keep comments and votes.

teetest commented on 2018-08-16 12:30

I agree with @jhernberg.

jhernberg commented on 2018-08-16 10:39

I suppose that technically it isn't really needed to rename the package, still in the past it's been mentioned by Justin that he doesn't have anything against open source. So I'd say that there is a small possibility to see it open sourced some day in the future.

Reading this: https://wiki.archlinux.org/index.php/Nonfree_applications_package_guidelines#Package_naming seems to suggest that reaper-bin would be the right choice.

IMO adding the -bin suffix also indicates to the user that this isn't a package built from source, but rather packages something available in binary form.

/opt is the choice of upstream so I think in order to facilitate support it's reasonable to use it.

SWS should really be installed into ~/.config/REAPER/UserPlugins/ even if it might work installed elsewhere. Also note that SWS isn't really maintained by anyone anymore, so there won't be regular or many updates at all to it.

It is available from landoleet as an already compiled tarball for those that can't build it themselves. I suppose ideally it should be available for download from http://www.sws-extension.org/ we'll see if that can be fixed someday, but without anyone really in charge of sws at the moment..:S

Is there some specific problem with having the package renamed to reaper-bin? IMO better to do so now, than maybe having to face problems in the future.

donvla commented on 2018-08-15 10:15

First why is it necessary to rename the package. As I understood the discussion, there should be no other option to install reaper than through the binary package. So reaper-bin is reaper. There is no other source package or similar.

Second, I'd recommend installing reaper into /usr/lib. I see no need in using /opt. It also breaks compatibility with plugins like sws.

I see this package as a drop-in replacement for the old reaper package which did not comply with the landoleet guidelines.

jhernberg commented on 2018-08-10 16:36

@David

Thanks!

david0 commented on 2018-08-10 15:42

THIS PACKAGE HAS BEEN RENAMED TO 'reaper-bin' (https://aur.archlinux.org/packages/reaper-bin)

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 install-reaper.sh script included in the tarball to install reaper, it was made for that. I'd recommend to run "sh install-reaper.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: https://www.reaper.fm/files/5.x/reaper594_linux_x86_64.tar.xz Shouldn't the PKGBUILD respect the above request from landoleet, I notice the tar from reaper.fm 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." http://reaper.fm/download.php#linux_download