Package Details: lib32-x265 1:4.0-4

Git Clone URL: https://aur.archlinux.org/lib32-x265.git (read-only, click to copy)
Package Base: lib32-x265
Description: Open Source H265/HEVC video encoder. 32bit libraries.
Upstream URL: https://bitbucket.org/multicoreware/x265_git
Licenses: GPL
Provides: libx265.so
Submitter: llde
Maintainer: unit73e
Last Packager: unit73e
Votes: 12
Popularity: 0.096280
First Submitted: 2017-08-24 18:30 (UTC)
Last Updated: 2025-04-20 21:53 (UTC)

Required by (19)

Sources (1)

Latest Comments

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

unit73e commented on 2025-04-20 12:46 (UTC) (edited on 2025-04-20 12:48 (UTC) by unit73e)

@Alex updated with your suggestion, with a message explaining why we are using cmake3-bin temporarily and not cmake. Thanks. The cmake3-bin package is also better than cmake3 because it's installing in the opt directory, without conflicting with cmake. That way we only really have to change PKGBUILD to use cmake3 instead of cmake.

unit73e commented on 2025-04-16 23:25 (UTC)

@Alex thanks for the info. Lets do that while there's no solution yet. I think it will take a while for cmake4 to work so I'll try in the next days. If someone here already managed to compile, maybe pull request, or send patch, or suggest being co-maintainer.

Alex commented on 2025-04-13 20:36 (UTC)

This package can be successfully built using cmake3 from the "cmake3-bin" AUR package (the normal cmake3 package also fails to build currently).

@unit73e not sure if you want to change this package for that or wait until upstream fixes cmake4 compatibility. Just wanted to comment in case it helps someone struggling to build this.

unit73e commented on 2025-04-09 21:27 (UTC) (edited on 2025-04-11 21:08 (UTC) by unit73e)

@vitaliikuzhdin just adding -DCMAKE_POLICY_VERSION_MINIMUM=3.5 doesn't work.

Looking upstream there's a patch for this issue: https://bitbucket.org/multicoreware/x265_git/commits/branch/master

However it's not in a stable version yet, so the solutions are wait for an upstream stable version, wait for x265 official package to come up with a solution, or create a git version of this library. At least I don't think patching is viable. It could work but there are several commits since 4.0, so its' not going to be the same thing as upstream.

unit73e commented on 2024-11-09 20:57 (UTC)

Updated to 4.0

unit73e commented on 2024-10-25 13:22 (UTC)

@oxalin @gnlrdrvo Adopted this package and updated to 3.6.

gnlrdrvo commented on 2024-08-25 06:30 (UTC)

@oxalin

I've submitted an orphan request for this package since the maintainer seems to be MIA for more than 2 years already.

Maybe you can consider taking over the maintainer role once the request is accepted?

oxalin commented on 2024-07-01 04:28 (UTC) (edited on 2024-07-01 04:31 (UTC) by oxalin)

Hi. Could you apply the following patch (the PKGBUILD part, and regenerate the .SRCINFO afterward) so the package can be updated to 3.6, on par with the native package's version: https://gitlab.archlinux.org/archlinux/packaging/packages/x265/-/commit/2c5a433fae98167293c04ae8aa6cf90fead1ff6f.patch

This will allow to build lib32-ffmpeg without manual intervention. Cheers.

TTsdzb commented on 2024-02-04 08:00 (UTC)

lib32-libnuma is now an orphan package. Please use another dependant instead.

Piscolero commented on 2023-11-10 10:09 (UTC) (edited on 2023-11-10 10:13 (UTC) by Piscolero)

cmake should be called with -G "Unix Makefiles" to fix problems if someone (like me) changed the default generator.

Or even better use cmake --build and cmake --install to be independent of generators at all.

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