[arch-proaudio] New package for dexed with standalone JACK client
Hi all, dexed, the well-known software synth closely modelled on the Yamaha DX7, recently added a standalone program to its deliverables. Since dexed is based on JUCE, adding JACK audio support to the standalone version was also easy: https://github.com/asb2m10/dexed/issues/131 To reflect this develoment, I have renamed the AUR package 'dexed-vst-git' to 'dexed-git' (merge pending) and have also created a new package 'dexed' for release 0.9.4 of dexed: https://aur.archlinux.org/packages/dexed-git/ https://aur.archlinux.org/packages/dexed/ Both packages install the native VST plugin and the standalone program, an icon and a desktop file. Share & Enjoy, Chris
On 2018-03-24T11:47:06 +0100 SpotlightKid <aur@chrisarndt.de> wrote:
Both packages install the native VST plugin and the standalone program, an icon and a desktop file.
'Ello! Thanks for doing this. Having trouble building the AUR package though (both dexed-git and dexed-vst-git give the same error): $ pacaur -y dexed-git :: resolving dependencies... :: looking for inter-conflicts... :: dexed-git and dexed-vst-git are in conflict (dexed-vst-git). Remove dexed-vst-git? [y/N] y AUR Packages (1) dexed-git-latest :: Proceed with installation? [Y/n] Y :: Retrieving package(s)... Cloning into 'dexed-git'... remote: Counting objects: 7, done. remote: Compressing objects: 100% (7/7), done. remote: Total 7 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (7/7), done. :: View dexed-git PKGBUILD? [Y/n] n :: Checking dexed-git integrity... ==> Making package: dexed-git 0.9.4.r226.a08cc25-2 (Sat 24 Mar 16:42:13 UTC 2018) ==> Retrieving sources... -> Cloning dexed git repo... Cloning into bare repository '/home/someone/var/cache/pacaur/dexed-git/dexed'... remote: Counting objects: 11655, done. remote: Compressing objects: 100% (939/939), done. remote: Total 11655 (delta 349), reused 618 (delta 234), pack-reused 10452 Receiving objects: 100% (11655/11655), 66.97 MiB | 378.00 KiB/s, done. Resolving deltas: 100% (7439/7439), done. -> Found dexed.desktop ==> Validating source files with md5sums... dexed ... Skipped dexed.desktop ... Passed :: Building dexed-git package(s)... ==> Making package: dexed-git 0.9.4.r226.a08cc25-2 (Sat 24 Mar 16:45:20 UTC 2018) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> WARNING: Using existing $srcdir/ tree ==> Starting pkgver()... ==> Starting build()... make: *** No rule to make target '../../JuceLibraryCode/include_juce_audio_plugin_client_VST2.cpp', needed by 'build/intermediate/Release/include_juce_audio_plugin_client_VST2_dd551e08.o'. Stop. ==> ERROR: A failure occurred in build(). Aborting... :: failed to build dexed-git package(s) -- Mark Raynsford | http://www.io7m.com
Am 24.03.2018 um 17:47 schrieb Mark Raynsford:
On 2018-03-24T11:47:06 +0100
$ pacaur -y dexed-git [...] ==> Making package: dexed-git 0.9.4.r226.a08cc25-2 (Sat 24 Mar 16:45:20 UTC 2018) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> WARNING: Using existing $srcdir/ tree ==> Starting pkgver()...
Hmm, that's strange. The 'prepare' function from the PKGBUILD doesn't seem to be executed. When I build the package with 'makepkg', the prepare function is run and outputs the following: [...] ==> Extracting sources... -> Creating working copy of dexed git repo... Switched to a new branch 'makepkg' ==> Starting prepare()... -> Enabling JACK audio in Dexed JUCE project file... JUCE v5.3.0 ********************************************************** Projucer 5.3.0 --- Build date: Mar 23 2018 Log started: 25 Mar 2018 2:21:54pm Linux CPU: 1562MHz Cores: 4 11593MB Loading project: /home/chris/src/arch/aur/dexed-git/src/dexed/Dexed.jucer Re-saving file: /home/chris/src/arch/aur/dexed-git/src/dexed/Dexed.jucer Finished saving: Linux Makefile - Builds/Linux JUCE Assertion failure in jucer_StoredSettings.cpp:334 JUCE Assertion failure in jucer_StoredSettings.cpp:328 Finished saving: Xcode (MacOSX) JUCE Assertion failure in jucer_StoredSettings.cpp:334 JUCE Assertion failure in jucer_StoredSettings.cpp:328 Finished saving: Visual Studio 2017 ==> Starting pkgver()... [...] Why does pacaur do this?
Am 24.03.2018 um 17:47 schrieb Mark Raynsford:
On 2018-03-24T11:47:06 +0100
$ pacaur -y dexed-git [...] ==> Making package: dexed-git 0.9.4.r226.a08cc25-2 (Sat 24 Mar 16:45:20 UTC 2018) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> WARNING: Using existing $srcdir/ tree ==> Starting pkgver()...
Hmm, that's strange. The 'prepare' function from the PKGBUILD doesn't seem to be executed. When I build the package with 'makepkg', the prepare function is run and outputs the following:
[...] ==> Extracting sources... -> Creating working copy of dexed git repo... Switched to a new branch 'makepkg' ==> Starting prepare()... -> Enabling JACK audio in Dexed JUCE project file... JUCE v5.3.0
********************************************************** Projucer 5.3.0 --- Build date: Mar 23 2018 Log started: 25 Mar 2018 2:21:54pm
Linux CPU: 1562MHz Cores: 4 11593MB Loading project: /home/chris/src/arch/aur/dexed-git/src/dexed/Dexed.jucer Re-saving file: /home/chris/src/arch/aur/dexed-git/src/dexed/Dexed.jucer Finished saving: Linux Makefile - Builds/Linux JUCE Assertion failure in jucer_StoredSettings.cpp:334 JUCE Assertion failure in jucer_StoredSettings.cpp:328 Finished saving: Xcode (MacOSX) JUCE Assertion failure in jucer_StoredSettings.cpp:334 JUCE Assertion failure in jucer_StoredSettings.cpp:328 Finished saving: Visual Studio 2017 ==> Starting pkgver()... [...]
Why does pacaur do this? Pacaur is essentially dead and should be replaced by something like aurutils or trizen, if one really needs that. Otherwise, always assume
On 2018-03-25 14:31:05 (+0200), SpotlightKid wrote: people use makepkg for building the package, as that's the only supported tool by the distribution. -- https://sleepmap.de
On Sun, 25 Mar 2018 14:48:23 +0200 David Runge <dave@sleepmap.de> wrote:
Pacaur is essentially dead and should be replaced by something like aurutils or trizen, if one really needs that. Otherwise, always assume people use makepkg for building the package, as that's the only supported tool by the distribution.
Or even better use a script from devtools like extra-x86_64-build, which will create a chroot with a base system, install all dependencies, and then build the packages. Of course it starts getting painful if you have dependencies from AUR. -- Joakim
On 2018-03-25 15:05:20 (+0200), Joakim Hernberg wrote:
On Sun, 25 Mar 2018 14:48:23 +0200 David Runge <dave@sleepmap.de> wrote:
Pacaur is essentially dead and should be replaced by something like aurutils or trizen, if one really needs that. Otherwise, always assume people use makepkg for building the package, as that's the only supported tool by the distribution.
Or even better use a script from devtools like extra-x86_64-build, Yes. This will also run some sanity checks on the package, after it has been built. For many many packages in the AUR, this would be very useful.
which will create a chroot with a base system, install all dependencies, and then build the packages. Of course it starts getting painful if you have dependencies from AUR. Hehe, yes. In such a case you would need a local repository to use devtools (e.g. with the help of aurutils), or have someone push the dependencies to [community].
Or even better use a script from devtools like extra-x86_64-build, which will create a chroot with a base system, install all dependencies, and then build the packages. Of course it starts getting painful if you have dependencies from AUR.
Note that aurutils uses devtools in the background. Pretty awesome, actually - and it can build your transitive dependencies from AUR as well ;) Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
On Sun, 25 Mar 2018 21:43:25 +0200, Bennett Piater wrote:
Or even better use a script from devtools like extra-x86_64-build, which will create a chroot with a base system, install all dependencies, and then build the packages. Of course it starts getting painful if you have dependencies from AUR.
Note that aurutils uses devtools in the background. Pretty awesome, actually - and it can build your transitive dependencies from AUR as well ;)
yaourt does this, too
Is there really anything wrong with yaourt at all if you add this to .bashrc? yaourt() { if [[ $@ =~ "-Si" ]]; then command echo "don't do that" else command yaourt "$@" fi } I'm sick of how much misinformation is still spread around with yaourt. On Sun, Mar 25, 2018 at 1:13 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sun, 25 Mar 2018 21:43:25 +0200, Bennett Piater wrote:
Or even better use a script from devtools like extra-x86_64-build, which will create a chroot with a base system, install all dependencies, and then build the packages. Of course it starts getting painful if you have dependencies from AUR.
Note that aurutils uses devtools in the background. Pretty awesome, actually - and it can build your transitive dependencies from AUR as well ;)
yaourt does this, too
On Sun, 25 Mar 2018 13:27:11 -0700, Jimi Bove wrote:
Is there really anything wrong with yaourt at all if you add this to .bashrc?
yaourt() { if [[ $@ =~ "-Si" ]]; then command echo "don't do that" else command yaourt "$@" fi }
I'm sick of how much misinformation is still spread around with yaourt.
Why not running "yaourt -Si"? Btw. now I noticed that the OP didn't use yaourt. I never heard of misinformation about yaourt. By default it builds in tmpfs, which could become an issue, if the available RAM is small and the binaries to build should be bloated, apart from this I'm not aware of any issue.
Oh, sorry. I didn't realize this discussion hadn't involved yaourt yet. It spurned me to look up package helpers again, which of course led to tons of false statements about flaws yaourt doesn't have anymore or never had, and an ArchWiki page that says it's no longer developed even though its last GitHub commit was 7 days ago. At least as far as I know (maybe yaourt's fixed this by now, too), running `yaourt -Si` on an AUR package results in the PKGBUILD being sourced, allowing malicious code to be executed if it's in there. And also as far as I know, that's the only flaw in yaourt, besides extremely minor ones like how it handles split packages and tmpfs, and ones that are just a feature it's missing that another AUR helper has. And yeah, the tmpfs thing is super minor. I can't a single modern-day use case for a computing device where both of the following are true: -Arch Linux is a great distro choice -There isn't plenty of RAM in the system I've certainly never filled up my tmp directory by compiling anything, which includes more than just things I installed through yaourt. I've also set it to be bigger than 4GB, but that's because there are so many so much more common programs to use than yaourt that might make you think 4GB is too small. On Sun, Mar 25, 2018 at 1:47 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sun, 25 Mar 2018 13:27:11 -0700, Jimi Bove wrote:
Is there really anything wrong with yaourt at all if you add this to .bashrc?
yaourt() { if [[ $@ =~ "-Si" ]]; then command echo "don't do that" else command yaourt "$@" fi }
I'm sick of how much misinformation is still spread around with yaourt.
Why not running "yaourt -Si"?
Btw. now I noticed that the OP didn't use yaourt. I never heard of misinformation about yaourt. By default it builds in tmpfs, which could become an issue, if the available RAM is small and the binaries to build should be bloated, apart from this I'm not aware of any issue.
On Sun, 25 Mar 2018 13:53:59 -0700, Jimi Bove wrote:
At least as far as I know (maybe yaourt's fixed this by now, too), running `yaourt -Si` on an AUR package results in the PKGBUILD being sourced, allowing malicious code to be executed if it's in there. And also as far as I know, that's the only flaw in yaourt, besides extremely minor ones like how it handles split packages and tmpfs, and ones that are just a feature it's missing that another AUR helper has.
Yes, I forgot about the split packages. An inexperienced user unfortunately would build a split package two times instead of one time. Not really an issue. I guess a real issue when yaourt is used by an inexperienced user, is the lexical order updated packages are build. If package "a" depends on package "b", we need to build "b" before we build "a", but yaourt would build "a" at first.
On 2018-03-25 22:13:18 (+0200), Ralf Mardorf wrote:
On Sun, 25 Mar 2018 21:43:25 +0200, Bennett Piater wrote:
Or even better use a script from devtools like extra-x86_64-build, which will create a chroot with a base system, install all dependencies, and then build the packages. Of course it starts getting painful if you have dependencies from AUR.
Note that aurutils uses devtools in the background. Pretty awesome, actually - and it can build your transitive dependencies from AUR as well ;)
yaourt does this, too yaourt uses devtools? Since when? I guess you're referring to the dependencies?
On Sun, 25 Mar 2018 22:41:46 +0200, David Runge wrote:
On 2018-03-25 22:13:18 (+0200), Ralf Mardorf wrote:
yaourt does this, too I guess you're referring to the dependencies?
Yes, I only wanted to point out that yaourt automatically allows to build required dependencies from AUR, too.
On Sun, 25 Mar 2018 22:52:09 +0200, Ralf Mardorf wrote:
On Sun, 25 Mar 2018 22:41:46 +0200, David Runge wrote:
On 2018-03-25 22:13:18 (+0200), Ralf Mardorf wrote:
yaourt does this, too I guess you're referring to the dependencies?
Yes, I only wanted to point out that yaourt automatically allows to build required dependencies from AUR, too.
Now a second issue comes to my mind, when using yaourt. If a user does use yaourt to upgrade packages from AUR, an inexperienced user could miss to build a package and it's dependencies in the required order.
Really? How so? Do you mean if a dependency of one of the package upgrades is the newer version of another upgrade that you haven't performed yet? I have to admit, I'm someone who never even thought of that and yet hasn't run into it in about 7 years of Arch. On Sun, Mar 25, 2018 at 1:59 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sun, 25 Mar 2018 22:52:09 +0200, Ralf Mardorf wrote:
On Sun, 25 Mar 2018 22:41:46 +0200, David Runge wrote:
On 2018-03-25 22:13:18 (+0200), Ralf Mardorf wrote:
yaourt does this, too I guess you're referring to the dependencies?
Yes, I only wanted to point out that yaourt automatically allows to build required dependencies from AUR, too.
Now a second issue comes to my mind, when using yaourt.
If a user does use yaourt to upgrade packages from AUR, an inexperienced user could miss to build a package and it's dependencies in the required order.
On Sun, 25 Mar 2018 14:06:47 -0700, Jimi Bove wrote:
Really? How so? Do you mean if a dependency of one of the package upgrades is the newer version of another upgrade that you haven't performed yet? I have to admit, I'm someone who never even thought of that and yet hasn't run into it in about 7 years of Arch.
PhotonX pinned one of my comments, see the first pinned comment at https://aur.archlinux.org/packages/shutter . This is one of the rare examples where the order to build packages is important.
Apart from the broken feature to dispaly AUR comments, the only issue with yaourt is tmpfs. Note, I'm using the plain makepkg approach as well as yaourt, but no other AUR tool. To workaround the tmpfs issue, you simply could add an alias, such as mine: alias naourt='echo "Not AnOther User Repository Tool";rm -rf /{.,}tmp/yaourt-tmp-$(id -un);yaourt --tmp /.tmp' However, I didn't try to build another/this DX7 clone, since my master keyboard is the first generation DX7 (brown metal case), I bought when I was a teenager, decades ago and nothing compares to it's output recorded with a RME card. I seriously doubt that an error such as "make: *** No rule to make target" is caused by using yaourt. Much likely it's either a broken PKGBUILD or an partial upgraded Arch Linux.
On 2018-03-25T14:48:23 +0200 David Runge <dave@sleepmap.de> wrote:
Pacaur is essentially dead and should be replaced by something like aurutils or trizen, if one really needs that. Otherwise, always assume people use makepkg for building the package, as that's the only supported tool by the distribution.
That's news to me, I had no idea. Basically picked it years ago and didn't actually pay attention to its development. I'll try something else. -- Mark Raynsford | http://www.io7m.com
Am 24.03.2018 um 11:47 schrieb SpotlightKid:
To reflect this develoment, I have renamed the AUR package 'dexed-vst-git' to 'dexed-git' (merge pending) and have also created a new package 'dexed' for release 0.9.4 of dexed:
https://aur.archlinux.org/packages/dexed-git/
https://aur.archlinux.org/packages/dexed/
Both packages install the native VST plugin and the standalone program, an icon and a desktop file.
I have uploaded a new release for both packages, because I discovered after releasing the previous ones, that the VST plug-in was broken on Linux in Dexed 0.9.4. This breakage was introduced with the addition of the stand-alone program, so the previous version 0.9.3 was stil working fine (but has no stand-alone program). I fixed this by having the PKGBUILD build the stand-alone version only first, then disable ALSA and JACK support and build the VST plug-in. This is a workaround until the underlying problem in JUCE is fixed. With this change it should also be possible to compile the packages with pacaur. Chris
participants (7)
-
Bennett Piater
-
David Runge
-
Jimi Bove
-
Joakim Hernberg
-
Mark Raynsford
-
Ralf Mardorf
-
SpotlightKid