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

1 2 3 4 5 Next › Last »

vitaliikuzhdin commented on 2025-04-20 21:53 (UTC)

@unit73e, I just noticed we are building from a git repo, which allows for a cleaner solution. I edited my message just a minute before you replied, so you probably didn't see it. If you want, you can update the PKGBUILD to use git cherry-pick without updating the pkgrel, but it's just cosmetic at this point.

Also, it doesn't hurt, but there is no need to increase the pkgrel when you increase the epoch.

Thank you for your very quick responses.

unit73e commented on 2025-04-20 21:53 (UTC)

@vitaliikuzhdin ok lets make it cleaner with a cherry pick and use `${url} instead of $url. Final version, I think.

unit73e commented on 2025-04-20 21:45 (UTC)

@vitaliikuzhdin yes cmake3 was still there. Need to pay more attention, good catch.

Now it should work with cmake4, and it's also a little bit more clean with a url variable and all options are in their own line. I think this is it. Btw I left it with source+= just because it was slightly prettier than a giant line, but with a variable it's ok.

vitaliikuzhdin commented on 2025-04-20 21:29 (UTC) (edited on 2025-04-20 21:43 (UTC) by vitaliikuzhdin)

@unit73e, you need to add epoch=1 to ensure everyone updates. Do not remove it with the next version; it can only be increased.

Also, the current PKGBUILD is still mistakenly using cmake3; you have probably forgotten to change that back.

Additionally, I somehow missed the fact that we are building from a git repo. In this case, it is probably easier not to add the patch to the sources and just use something like this:

prepare() {
  cd "${pkgname#lib32-*}"
  # Fix CMake build error with latest CMake 4.0 release
  git cherry-pick b354c009a60bcd6d7fc04014e200a1ee9c45c167
}

unit73e commented on 2025-04-20 21:23 (UTC)

@sl1pkn07 fixed. now it's 4.0-2. Unfortunately that means whoever updated to 4.1 needs to downgrade manually. Thanks for noticing, I forgot to undo my update version experiment.

@vitaliikuzhdin your suggestion was clever and worked very well. It's compatible with cmake4 now.

unit73e commented on 2025-04-20 21:12 (UTC)

@sl1pkn07 because I messed up. I'll fix it with cmake4 if possible.

sl1pkn07 commented on 2025-04-20 21:02 (UTC)

why is version newer than x265[extra]?

vitaliikuzhdin commented on 2025-04-20 20:51 (UTC)

@unit73e, you will get an error if you don't remove the patch with the next update, so unless you don't build the packages before uploading them, you will definitely notice it:

==> Starting prepare()...
patching file source/CMakeLists.txt
Reversed (or previously applied) patch detected!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file source/CMakeLists.txt.rej
==> ERROR: A failure occurred in prepare().
    Aborting...

unit73e commented on 2025-04-20 20:44 (UTC)

@vitaliikuzhdin if it's just that it's acceptable, but we'll have to remember that was a thing when upstream fixes the problem. Better than cmake3-bin. Thanks.

vitaliikuzhdin commented on 2025-04-20 20:33 (UTC) (edited on 2025-04-20 20:43 (UTC) by vitaliikuzhdin)

@unit73e, you just need to apply b354c009a60bcd6d7fc04014e200a1ee9c45c167 to fix it. Add something like source+=("x265_cmake4.patch::https://bitbucket.org/multicoreware/x265_git/commits/b354c009a60bcd6d7fc04014e200a1ee9c45c167/raw") and add a prepare() function.

1 2 3 4 5 Next › Last »