| Git Clone URL: | https://aur.archlinux.org/lib32-ffmpeg.git (read-only, click to copy) |
|---|---|
| Package Base: | lib32-ffmpeg |
| Description: | Complete solution to record, convert and stream audio and video (32 bit) |
| Upstream URL: | http://ffmpeg.org |
| Licenses: | GPL-3.0-only |
| Conflicts: | lib32-libffmpeg |
| Provides: | libavcodec.so, libavdevice.so, libavfilter.so, libavformat.so, libavutil.so, libpostproc.so, libswresample.so, libswscale.so |
| Replaces: | lib32-libffmpeg |
| Submitter: | lano1106 |
| Maintainer: | oxalin |
| Last Packager: | oxalin |
| Votes: | 37 |
| Popularity: | 0.006711 |
| First Submitted: | 2013-05-18 04:43 (UTC) |
| Last Updated: | 2024-09-27 17:48 (UTC) |
No problem at all, my friend :)
But why don't you just define this?
source=("git+https://git.ffmpeg.org/ffmpeg.git#tag=n${pkgver}"
That way, you'll never have to know the commit hash of each tag, and you'll just need to edit the pkgver field.
Using the hash of the tags makes the process more error prone - I don't blame you! :) My aim was to suggest an easier and more maintainer-friendly solution. :)
@MarsSeed: Well, I've mixed up things yesterday in the PKGBUILD. I was not thinking straight it seems or I had my eyes crossed. The good version should be in in a few minutes.
The _tag should be n5.0.1, not 9687cae2b468e09e35df4cea92cc2e6a0e6c93b3. :)
@oxalin
I think you forgot to update the _tag to 9687cae2b468e09e35df4cea92cc2e6a0e6c93b3
@oxalin
Ok so i solved the issue by installing "clang" package. Seems it is required as a makedepend (instead of lib32-clang maybe ?)
@oxalin @tomato I think the issue does not occur for you because you already have installed (manually) "clang" package in your system.
@oxalin
Sorry for delay (i didn't received mail notification..).
Some points:
I looked at your patch but it is old (feb. 2021). It is already merged in current version of this AUR package. Nothing to patch here
I don't have any Nvidia hardware, just a simple Intel Iris Xe based laptop.
The issue remains as of today
This issue is pretty annoying because this package is a dependency for many others.
Hope it helps.
@sgt-hartman and @Tomato: is patching the source code with https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/52cc323735ced6e8095cfd3acea0e36e35c76eb2 helps?
I'm getting the ERROR: cuda_llvm requested but not found error too.
What's weird is that I'm getting it only when I try to build in a clean chroot (with makechrootpkg -r $CHROOT -I ../lib32-aom/lib32-aom..., but NOT when I build it in my regular OS using yay
@npfeiler : as it is done for many lib32 packages, there is a dependency on the native package. Mostly, the header files are provided by the native package (64 bit), so if any other lib32 package needs to be built with a dependency on {lib32-}ffmpeg, it needs to have access to the header files.
Other distros sometime provide a specific package for header files (identified by a "-dev" at the end of the package's name), but it is not the way of Arch.
I couldn’t figure out what exactly in this package has a dependency on 64 bit ffmpeg, does anyone know?
Pinned Comments
oxalin commented on 2024-04-09 22:05 (UTC)
For those wondering: I intentionally keep this package as close to the native package as possible, to the extent of the available dependencies. FFMPEG package sees a lot of modifications through time and I prefer to follow the changes applied to the native PKGBUILD as much as possible. The more it goes, the more flags are added and the more often we need to cherrypick commits (until a new release comes in).
This means I'll keep the dependencies around even if there is no obvious usecase for them.
Also, since openjpeg2 is still used with the native package, I'll also keep it around. Last thing I read about the JPEG2000 internal decoder was that it was faster, but that it was still introducing errors in the rendering. This probably explains why it is still enable in the native package. I look at it once in a while and things may have evolved since, but a quick checkup didn't bring up any tangible answer.
Now, if someone would like to take the ownership of this package, I would be more than pleased to hand it over. The same goes for any related packages that I maintain mostly for FFMPEG. lib32-libffmpeg and lib32-ffmpeg could be merged back together to simplify its maintenance.
Let me know if this is something you're interested in.
oxalin commented on 2018-02-25 07:37 (UTC) (edited on 2020-05-25 15:55 (UTC) by oxalin)
About GPG, it is up to you to import the missing public key. If you receive an error about it, this is ffmpeg's project public key. Something like the following should do the trick: gpg --recv-keys B4322F04D67658D8