Package Details: zynaddsubfx-git 3.0.6.r122.g07308dd8-1

Git Clone URL: https://aur.archlinux.org/zynaddsubfx-git.git (read-only, click to copy)
Package Base: zynaddsubfx-git
Description: A powerful realtime, multi-timbral software synthesizer.
Upstream URL: http://zynaddsubfx.sourceforge.net
Licenses: GPL-2.0-or-later
Conflicts: zynaddsubfx
Provides: zynaddsubfx
Submitter: speps
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 17
Popularity: 0.004045
First Submitted: 2011-07-09 23:54 (UTC)
Last Updated: 2024-09-13 23:34 (UTC)

Required by (1)

Sources (28)

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

Moxon commented on 2016-08-02 18:09 (UTC) (edited on 2016-08-02 18:10 (UTC) by Moxon)

WoefulDerelict: I am humbled by your efforts to recreate the bug. I checked my makepkg.conf and BUILDDIR is the only variable which has been changed by me. Even worse and probably embarassing for me: I cannot reproduce the error any more. I can only guess that it was some glitch in my system which went away either by rebooting or by updating the system - zynaddsubfx-git was just successfully compiled and installed on my machine. Thank you for taking care of this piece of software in arch, it enables me to make music (which probably only I like) with a fine soft synthesizer.

WoefulDerelict commented on 2016-07-21 01:30 (UTC) (edited on 2016-07-21 01:38 (UTC) by WoefulDerelict)

Moxon: That is, of course, your prerogative. Unfortunately I have been completely unable to reproduce the reported behaviour on a multitude of systems. The package builds fine in a clean test environment (https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot) as well as on test boxes with nothing more than a pacstrap of base and base-devel: even when building in /tmp on machines with as little as 1GB of RAM. Not even yaourt misbehaves and it also builds in /tmp. If I parse the output you shared correctly your build isn't even managing to properly retrieve the sources. The fetch data is all off and it appears to be looking for the git repository is a very, very strange place '/var/cache/pacman/pkg/zynaddsubfx-git27501/zynaddsubfx-git/zynaddsubfx-git' This is definitely not the default location for package sources. If makepkg has a BUILDDIR of /tmp/makepkg the primary location it should be working with is '/tmp/makepkg/zynaddsubfx-git' along with the source, which by default is downloaded to the same directory the PKGBUILD resides in. If you have modified other variables in makepkg.conf like SRCDEST they could be responsible for altering the default behaviour and the root of your current issue. If there is not enough space to download the sources it could result in the errors you're experiencing. If you compare the output you provided with the following output from a healthy build you should notice that the git repo has more data than is being reported/retrieved on your system which would explain why it does not appear to be a valid repository when git attempts to work with it: it's incomplete. ==> Retrieving sources... -> Cloning zynaddsubfx-git git repo... Cloning into bare repository '/home/llewelyn/ArchPackageSources/Workspace/zynaddsubfx-git/zynaddsubfx-git'... remote: Counting objects: 20923, done. remote: Compressing objects: 100% (6615/6615), done. remote: Total 20923 (delta 17027), reused 18030 (delta 14292) Receiving objects: 100% (20923/20923), 6.33 MiB | 82.00 KiB/s, done. Resolving deltas: 100% (17027/17027), done. Checking connectivity... done. -> Downloading unsortedzynaddsubfxParameters_20140402.zip... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1134k 100 1134k 0 0 616k 0 0:00:01 0:00:01 --:--:-- 616k ==> Validating source files with sha512sums... zynaddsubfx-git ... Skipped unsortedzynaddsubfxParameters_20140402.zip ... Passed ==> Extracting sources... -> Creating working copy of git repo... Cloning into 'zynaddsubfx-git'... done. ==> Starting prepare()... Already on 'master' Your branch is up-to-date with 'origin/master'. Submodule 'DPF' (git://github.com/DISTRHO/DPF) registered for path 'DPF' Submodule 'instruments' (git://git.code.sf.net/p/zynaddsubfx/instruments) registered for path 'instruments' Submodule 'rtosc' (https://github.com/fundamental/rtosc) registered for path 'rtosc' Cloning into '/home/llewelyn/ArchPackageSources/Workspace/zynaddsubfx-git/src/zynaddsubfx-git/DPF'... Cloning into '/home/llewelyn/ArchPackageSources/Workspace/zynaddsubfx-git/src/zynaddsubfx-git/instruments'... Cloning into '/home/llewelyn/ArchPackageSources/Workspace/zynaddsubfx-git/src/zynaddsubfx-git/rtosc'... Submodule path 'DPF': checked out '79dfcc97e4e153daec564774c418d68ca1130e59' Submodule path 'instruments': checked out 'fc0624067d980a36a3826ccdf6694c993c7d3862' Submodule path 'rtosc': checked out '0771cb1f29a68d13bb8ec00abaaafcb54cb1366e' One thing of which I am certain at this point, having conducted thorough build testing on multiple machines, is that the issue is specific to your system, likely the result of deviating from the standard distribution configuration, not this package.

Moxon commented on 2016-07-20 18:43 (UTC) (edited on 2016-07-20 18:45 (UTC) by Moxon)

Hm. I beg to differ. With 4.9GB on /tmp even zynaddsubfx should be able to compile. It is the only package which fails, all others from AUR work. Also the error occurs even before the compilation starts and does not hint towards a out of space error.

WoefulDerelict commented on 2016-07-18 18:41 (UTC)

Moxon: Unfortunately this problem exists not with any package or even in opting to use /tmp/makepkg as your BUILDDIR but between the keyboard and chair. If you had bothered to consult the documentation you would know that the default behaviour on Arch is that /tmp exists on tmpfs which is limited to half of the system memory (https://wiki.archlinux.org/index.php/Tmpfs). The build is failing because your system does not have enough space in tmpfs to house the build. This limitation is one of the key reasons /tmp/makepkg is not used by default and why yaourt attracts the most negative feedback of any AUR helper as it attempts to build in tmpfs by default. You can solve this problem by either building outside of tmpfs or by adjusting the maximum size of your tmpfs by following the procedure on the tmpfs page of the Arch Wiki.

Moxon commented on 2016-07-18 14:12 (UTC)

This might be a problem with not just this package, but: If you set BUILDDIR in /etc/makepkg.conf to e.g. /tmp/makepkg, the build fails early with this error message: $ makepkg -sir ==> Making package: zynaddsubfx-git 2.5.4.r40.gd920f8b-1 (Sun Jul 17 14:17:38 CEST 2016) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Updating zynaddsubfx-git git repo... Fetching origin remote: Counting objects: 538, done. remote: Compressing objects: 100% (120/120), done. remote: Total 389 (delta 318), reused 329 (delta 269) Receiving objects: 100% (389/389), 77.59 KiB | 0 bytes/s, done. Resolving deltas: 100% (318/318), completed with 88 local objects. From git://git.code.sf.net/p/zynaddsubfx/code 731722e..5f420f5 master -> master * [new branch] unique_version -> unique_version -> Found unsortedzynaddsubfxParameters_20140402.zip ==> Validating source files with sha512sums... zynaddsubfx-git ... Skipped unsortedzynaddsubfxParameters_20140402.zip ... Passed ==> Extracting sources... -> Creating working copy of git repo... fatal: '/var/cache/pacman/pkg/zynaddsubfx-git27501/zynaddsubfx-git/zynaddsubfx-git' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ==> ERROR: Failure while updating working copy of git repo Aborting...

<deleted-account> commented on 2015-04-08 01:58 (UTC)

I also hit the X11 linking error. Here's the ugly workaround I used to get it built: In zynaddsubfx-git/src/CMakeLists.txt add ${X11_LIBRARIES} beneath ${GUI_LIBRARIES} on line 371. Good luck!

cocreature commented on 2015-03-25 08:54 (UTC)

I'm getting the same error haby is getting.

habys commented on 2015-03-24 18:56 (UTC)

Some kinda linking errors with X11 trying to build today: libzynaddsubfx_core.a(Master.cpp.o): In function `memset': /usr/include/bits/string3.h:86: warning: memset used with constant zero length parameter; this could be due to transposed parameters /usr/bin/ld: UI/libzynaddsubfx_gui.a(MasterUI.cxx.o): undefined reference to symbol 'XCreateBitmapFromData' /usr/lib/libX11.so.6: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status src/CMakeFiles/zynaddsubfx.dir/build.make:95: recipe for target 'src/zynaddsubfx' failed make[2]: *** [src/zynaddsubfx] Error 1 CMakeFiles/Makefile2:1760: recipe for target 'src/CMakeFiles/zynaddsubfx.dir/all' failed make[1]: *** [src/CMakeFiles/zynaddsubfx.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... libzynaddsubfx_core.a(Master.cpp.o): In function `memset': /usr/include/bits/string3.h:86: warning: memset used with constant zero length parameter; this could be due to transposed parameters [100%] Built target zynaddsubfx_dssi Makefile:126: recipe for target 'all' failed make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

Potomac commented on 2015-03-14 09:35 (UTC)

there is a problem with this package : the PKGBUILD needs to be rewritten, because the /usr/lib64 directory is used, and pacman doesn't want to install this package because there is a conflict directory with /usr/lib64 and the symbolic link "/usr/lib64", the solution is to add these lines in package() section in the PKGBUILD : # move files from /usr/lib64 to /usr/lib mkdir $pkgdir/usr/lib mv $pkgdir/usr/lib64/* $pkgdir/usr/lib rm -rf $pkgdir/usr/lib64

cocreature commented on 2014-09-06 20:07 (UTC)

Awesome, you finally did update the package thx. /usr/bin/ontroller and /usr/bin/splitter don't have the executable bit set, you should add that.

« First ‹ Previous 1 2 3 4 Next › Last »