@nfnty: qt5-svg needs to be switched to qt6-svg, gtk2 replaced with gtk2-compat, movit requires eigne3 in makedepends[], missing qt6-5compat and qt5-base in makedepends[]
Search Criteria
Package Details: mlt-git 7.22.0.r27.30115615-1
Package Actions
| Git Clone URL: | https://aur.archlinux.org/mlt-git.git (read-only, click to copy) |
|---|---|
| Package Base: | mlt-git |
| Description: | Multimedia Framework |
| Upstream URL: | https://github.com/mltframework/mlt |
| Licenses: | LGPL2.1 |
| Conflicts: | mlt |
| Provides: | mlt |
| Submitter: | agapito |
| Maintainer: | nfnty (evorster) |
| Last Packager: | evorster |
| Votes: | 42 |
| Popularity: | 0.000000 |
| First Submitted: | 2009-08-26 09:32 (UTC) |
| Last Updated: | 2024-03-07 13:24 (UTC) |
Dependencies (23)
- ffmpeg (ffmpeg-nvcodec-11-1-gitAUR, ffmpeg-ffplayoutAUR, ffmpeg-cudaAUR, ffmpeg-gitAUR, ffmpeg-amd-fullAUR, ffmpeg-amd-full-gitAUR, ffmpeg-headlessAUR, ffmpeg-libfdk_aacAUR, ffmpeg-decklinkAUR, ffmpeg-obsAUR, ffmpeg-fullAUR, ffmpeg-full-gitAUR)
- gdk-pixbuf2 (gdk-pixbuf2-gitAUR, gdk-pixbuf2-noglycinAUR)
- libarchive (libarchive-gitAUR)
- libebur128 (libebur128-gitAUR)
- libsamplerate (libsamplerate-gitAUR)
- movit (movit-gitAUR)
- opencv (opencv-cuda)
- qt5-svg (qt5-svg-gitAUR)
- rtaudio (rtaudio-gitAUR)
- rubberband
- sdl12-compat (sdl12-compat-gitAUR)
- sox (sox-dsd-gitAUR)
- vid.stab
- cmake (cmake3AUR, cmake-gitAUR) (make)
- frei0r-plugins (frei0r-plugins-gitAUR) (make)
- git (git-gitAUR, git-glAUR) (make)
- gtk2AUR (gtk2-patched-filechooser-icon-viewAUR) (make)
- ladspa (make)
- libdv (make)
- libexif (libexif-gitAUR) (make)
- Show 3 more dependencies...
Required by (9)
- flowblade-git (requires mlt)
- kdenlive-git (requires mlt)
- kdenlive-release-git (requires mlt)
- krita-git (requires mlt)
- shotcut-bin (requires mlt)
- shotcut-git (requires mlt)
- synfig-dev (requires mlt)
- synfig-git (requires mlt)
- webvfx (requires mlt)
Sources (2)
bartus commented on 2025-11-14 14:18 (UTC) (edited on 2025-11-14 14:33 (UTC) by bartus)
btw.
eclairevoyant commented on 2023-05-21 02:01 (UTC) (edited on 2023-05-21 02:03 (UTC) by eclairevoyant)
Upstream does versioned releases, so the pkgver should reflect that:
pkgver() {
git -C $_gitname describe --long --tags | sed 's/^v//;s/\([^-]*-\)g/r\1/;s/-/./g'
}
This produces the more accurate version 7.16.0.r16.56b1f62f.
(A similar example is available in /usr/share/pacman/PKGBUILD-vcs.proto, but that has a leading v and assumes all tags are annotated, which they aren't here.)
epoch does not need to be bumped btw, as per pacman's vercmp, numbers are strictly greater than letters, so the new version will be considered "increasing".
Also, license should be corrected to LGPL2.1.
Riedler commented on 2023-04-02 17:38 (UTC)
paru always updates the source. I removed it anyway so I could be sure. didn't help. Although this time it got to 92%…?
I'm simply going to try again. At this rate, the next compilation has to go to 100% :I
evorster commented on 2023-04-02 17:22 (UTC)
One crucial difference is that I use Yay locally. That has a --cleanbuild option which also removes the source and tries again with a clean slate, and a failed build might very well cause a later build to fail if some of the previous build files are still hanging around.
On Yay you can also manually for this by removing the ./src directory where the PKGBUILD resides, which will force the PKGBUILD to check out a new copy of the source from it's local git repo.
Riedler commented on 2023-04-02 17:07 (UTC)
I mean, your package does that, no? Anyway, I compiled it manually while looking at your PKGBUILD and it …worked? what?
I even deleted all of the stuff paru caches for AUR compilation and retried, but the PKGBUILD produces the same error as always and manual compilation with the same commands doesn't.
huh????
I commented the custom CFLAGS and LDFLAGS again because what the hell and that doesn't fix it either, although the compilation at least got to 78% instead of the ~40% the previous runs had. But also the compilation was way slower. Maybe a job ordering thing? idk
evorster commented on 2023-04-02 16:13 (UTC)
Just chatted with the creator of MLT. He believes this error is already fixed. Can you please pull the latest version of the source from git and try again, please?
Riedler commented on 2023-04-02 15:57 (UTC)
normally yes, but I disabled them because I thought they might be the problem. Looks like they aren't.
evorster commented on 2023-04-02 15:55 (UTC)
Interesting. Do you have custom LDFLAGS of compiler flags set?
Riedler commented on 2023-04-02 15:40 (UTC)
nope, still doesn't compile on my machine
evorster commented on 2023-04-02 15:37 (UTC)
@Riedler this may be a transient thing, git repos are not always guaranteed to compile. I have just tried to compile it on my machine, and it worked flawlessly. If the problem persists, please make another comment and I'll pass it along to the upstream repo
Pinned Comments
nfnty commented on 2015-12-27 08:48 (UTC)