Search Criteria
Package Details: vapoursynth-editor r19_mod_6.10-4
Package Actions
| 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
Nah, sorry, I don't really like verbosity for the sake of verbosity.
glibcandlibgccare core OS/AUR dependencies, you can't run Arch Linux and install stuff from the AUR without them.qt6-baseis practically explicit, asqt6-websocketssimply can't exist on its own without pulling its parent package.libstdc++is a dependency ofgccandqt6-base, not ofvapoursynth-editoritself.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-5compatjust slipped my mind.Thanks, fixed.
HurricanePootis commented on 2026-05-17 00:20 (UTC)
@Nocifer,
I just built
vapoursynth-editorin a clean chroot usingextra-x86-64-build -c. I have a few recommendations and one fix for your package:libstdc++,glibc,libgcc, andqt6-baseto your PKGBUILD. These are implicitly implied, but its always good to be verbose in yourdepends().qt6-5compatfromdepends(). Maybevapoursynth-editorrelied on this in the past, but it no longer requires it.vsedit.installscript. You forgot to enclose one of theechos, causing thepost_install()function to fail. Maybe you never caught this, since it only fails after a clean install.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
!ltobased on just my personal experience was probably a bit hasty.Unfortunately, the bad news is that even with
!ltothe build can still fail with linking errors, it's just much less frequent. I just tested and with!ltoI had 4 out of 10 back-to-back builds fail, while without!lto(let alone with a linker other thanmold) 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 onmold, 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:
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:
Recently, I found out painfully that some parallel stuff (like
libcubafor 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-gitversion compiles with the samemakepkg.configwithout a hindrance. It is either thePKGBUILDor some GitHub-exclusive changes that seem to matter here.1 2 3 Next › Last »