Package Details: vapoursynth-editor r19_mod_6.10-4

Git Clone URL: https://aur.archlinux.org/vapoursynth-editor.git (read-only, click to copy)
Package Base: vapoursynth-editor
Description: Editor for VapourSynth scripts
Upstream URL: https://github.com/YomikoR/VapourSynth-Editor
Keywords: vapoursynth
Licenses: MIT
Submitter: alucryd
Maintainer: Nocifer
Last Packager: Nocifer
Votes: 16
Popularity: 0.073956
First Submitted: 2014-08-21 20:02 (UTC)
Last Updated: 2026-05-17 12:11 (UTC)

Latest Comments

1 2 3 Next › Last »

Nocifer commented on 2026-05-17 12:11 (UTC) (edited on 2026-05-17 12:12 (UTC) by Nocifer)

@HurricanePootis

  1. Nah, sorry, I don't really like verbosity for the sake of verbosity.

    • glibc and libgcc are core OS/AUR dependencies, you can't run Arch Linux and install stuff from the AUR without them.

    • qt6-base is practically explicit, as qt6-websockets simply can't exist on its own without pulling its parent package.

    • libstdc++ is a dependency of gcc and qt6-base, not of vapoursynth-editor itself.

  2. Thanks, I did notice that upstream had been doing some work on better Qt6 support in between versions 6.8 and 6.9, but for 6.9 and 6.10 I was too focused on making it work with Vapoursynth R74 and testing again for qt6-5compat just slipped my mind.

  3. Thanks, fixed.

HurricanePootis commented on 2026-05-17 00:20 (UTC)

@Nocifer,

I just built vapoursynth-editor in a clean chroot using extra-x86-64-build -c. I have a few recommendations and one fix for your package:

  1. Add libstdc++, glibc, libgcc, and qt6-base to your PKGBUILD. These are implicitly implied, but its always good to be verbose in your depends().
  2. Remove qt6-5compat from depends(). Maybe vapoursynth-editor relied on this in the past, but it no longer requires it.
  3. Fix the vsedit.install script. You forgot to enclose one of the echos, causing the post_install() function to fail. Maybe you never caught this, since it only fails after a clean install.
diff --git a/PKGBUILD b/PKGBUILD
index b154534..898151f 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -10,7 +10,7 @@ pkgdesc='Editor for VapourSynth scripts'
 arch=('x86_64')
 url='https://github.com/YomikoR/VapourSynth-Editor'
 license=('MIT')
-depends=('qt6-5compat' 'qt6-websockets' 'vapoursynth>=74')
+depends=('qt6-websockets' 'vapoursynth>=74' 'hicolor-icon-theme' 'libstdc++' 'glibc' 'libgcc' 'qt6-base')
 install='vsedit.install'
 source=("https://github.com/YomikoR/VapourSynth-Editor/archive/refs/tags/${_pkgver}.tar.gz"
         'vsedit.desktop'
diff --git a/vsedit.install b/vsedit.install
index 12895d5..49ff7d0 100644
--- a/vsedit.install
+++ b/vsedit.install
@@ -1,5 +1,5 @@
 post_install() {
-    echo "In order to properly work with Vapoursynth >=74, Vapoursynth Editor needs to export
+    echo "In order to properly work with Vapoursynth >=74, Vapoursynth Editor needs to export"
     echo "the environment variable 'VSSCRIPT_PATH' by installing '/etc/profile.d/vsedit.sh',"
     echo "but please be aware that this will take effect only after you reboot your system."
 }

Ranguvar commented on 2026-05-08 18:03 (UTC)

6.10-3 built for me on the first try, without any changes.

Good solution, thanks again!

Nocifer commented on 2026-05-07 12:11 (UTC) (edited on 2026-05-07 12:12 (UTC) by Nocifer)

Hmm, on my system it was no longer failing with LTO enabled when I was testing it before I pushed the previous update, but since these kinds of linking errors are usually intermittent and also are very much affected by the build environment, I guess the removal of !lto based on just my personal experience was probably a bit hasty.

Unfortunately, the bad news is that even with !lto the build can still fail with linking errors, it's just much less frequent. I just tested and with !lto I had 4 out of 10 back-to-back builds fail, while without !lto (let alone with a linker other than mold) the frequency rises to something like 9 out of 10.

A much more reliable way I have found to ensure (?) a successful build is to do it single-threaded, i.e. with the Arch default MAKEFLAGS=-j2, which is what I have now opted to do in this PKGBUILD for the time being. This also removes the need to have a hard dependency on mold, with the tradeoff being a comparatively much longer build time.

Let's see how this goes; and if you still get any errors, please report them here.

Ranguvar commented on 2026-05-06 20:07 (UTC)

Thank you for the update with /etc/profile.d/vsedit.sh

It seems to work well.

However I had to add back in options=('!lto') or build broke with my system-wide LTO config.

Nocifer commented on 2026-04-06 19:31 (UTC) (edited on 2026-04-09 07:26 (UTC) by Nocifer)

Yeah, even though the release notes mention that this new update should still be able to work with Vapoursynth R73, unfortunately it seems that it's only compatible with R74 and anything below that breaks apart, something I found out after I had already pushed the update.

Vapoursynth R74 was released just yesterday, so Arch still has it at R73, but hopefully the update won't be much longer and will sort things out. Or if not, then I'll look into the issue more closely.

EDIT: I built R74 on my own and I can confirm that it works just fine with vapoursynth-editor 6.9. Beware though that R74 is apparently a very different beast compared to R73 (different build process, different library path, different process invocation) so some plugins may be prone to break until they are properly updated.

EDIT 2: I've come to realize that upgrading Vapoursynth to R74 will break not only its plugins but also any third-party apps that directly depend on it, which will require a rebuild as well; they are only a handful but include such non-trivial apps as MPV and FFmpeg, so I guess the R74 update may take a bit longer to land after all.

Win8Error commented on 2026-04-06 18:22 (UTC) (edited on 2026-04-06 18:23 (UTC) by Win8Error)

Sadly can't open any previews.

Editor log says:

2026-04-06 20:16:48.976
Library found in but failed to get VSScript API!
2026-04-06 20:16:48.977
Failed to get VSScript API!

My vapoursynth version is 73-2 from the extra repo.

Rus commented on 2024-07-31 21:59 (UTC)

compiled and works without problems

but other necessary VS software does not compile because of ffmpeg7 (or other updates) >_<

Nocifer commented on 2024-07-20 16:06 (UTC)

When building in a chroot for testing purposes I too encountered a similar issue and my build also failed, but when I tried to reproduce it in my normal environment it built successfully, and then when I tried once more in a chroot it again built successfully.

This has been an issue for some time now (see the previous comments) and as it is rather intermittent, I've concluded that it's probably a bug in the upstream code itself (or maybe in Qt 6.7) that makes the linker fail.

My advice to you: try rebuilding the package a few times, and at some point it will probably succeed. And if you happen to find a solution, or even a hint to a possible solution, please do share it here.

Fifis commented on 2024-07-20 08:30 (UTC)

This fails on my machine:

/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o: in function `EncodeDialog::~EncodeDialog()':
encode_dialog.cpp:(.text+0x177): undefined reference to `vtable for EncodeDialog'
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o: in function `EncodeDialog::~EncodeDialog()':
encode_dialog.cpp:(.text+0x237): undefined reference to `vtable for EncodeDialog'
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o: in function `non-virtual thunk to EncodeDialog::~EncodeDialog()':
encode_dialog.cpp:(.text+0x307): undefined reference to `vtable for EncodeDialog'
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o: in function `non-virtual thunk to EncodeDialog::~EncodeDialog()':
encode_dialog.cpp:(.text+0x3d8): undefined reference to `vtable for EncodeDialog'
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o: in function `EncodeDialog::slotStartEncodeButtonPressed()':
encode_dialog.cpp:(.text+0x7d4): undefined reference to `EncodeDialog::staticMetaObject'
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o: in function `EncodeDialog::slotJobProgressChanged()':
encode_dialog.cpp:(.text+0x930): undefined reference to `EncodeDialog::staticMetaObject'
/usr/bin/ld: encode_dialog.cpp:(.text+0xa5b): undefined reference to `EncodeDialog::staticMetaObject'
/usr/bin/ld: encode_dialog.cpp:(.text+0xc2f): undefined reference to `EncodeDialog::staticMetaObject'
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o: in function `EncodeDialog::initialize(QString const&, QString const&)':
encode_dialog.cpp:(.text+0x10cb): undefined reference to `EncodeDialog::staticMetaObject'
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o:encode_dialog.cpp:(.text+0x1148): more undefined references to `EncodeDialog::staticMetaObject' follow
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o: in function `EncodeDialog::slotWriteLogMessage(QString const&, QString const&)':
encode_dialog.cpp:(.text+0x14ba): undefined reference to `EncodeDialog::signalWriteLogMessage(QString const&, QString const&)'
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o: in function `EncodeDialog::slotEncodingPresetComboBoxActivated(QString const&)':
encode_dialog.cpp:(.text+0x1860): undefined reference to `EncodeDialog::staticMetaObject'
/usr/bin/ld: encode_dialog.cpp:(.text+0x19f3): undefined reference to `EncodeDialog::staticMetaObject'
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o: in function `EncodeDialog::setUpEncodingPresets()':
encode_dialog.cpp:(.text+0x1d35): undefined reference to `EncodeDialog::staticMetaObject'
/usr/bin/ld: encode_dialog.cpp:(.text+0x1dbc): undefined reference to `EncodeDialog::staticMetaObject'
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o: in function `EncodeDialog::slotEncodingPresetSaveButtonPressed()':
encode_dialog.cpp:(.text+0x2116): undefined reference to `EncodeDialog::staticMetaObject'
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o:encode_dialog.cpp:(.text+0x2366): more undefined references to `EncodeDialog::staticMetaObject' follow
/usr/bin/ld: ../../vsedit/generated/obj-release-64bit-gcc/encode_dialog.o: in function `EncodeDialog::EncodeDialog(SettingsManager*, VSScriptLibrary*, QWidget*)':
encode_dialog.cpp:(.text+0x356f): undefined reference to `vtable for EncodeDialog'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:611: ../../build/release-64bit-gcc/vsedit] Error 1

Recently, I found out painfully that some parallel stuff (like libcuba for scientific computations) fails at the linking stage if the number of cores exceeds 7. However, here it does not seem to be the problem because the -git version compiles with the same makepkg.config without a hindrance. It is either the PKGBUILD or some GitHub-exclusive changes that seem to matter here.