Arch Linux User Repository

Shall be fixed and compiles with OpenEXR 3.0.

Thanks again for all this valuable feedback. Indeed I have to improve my PKGBUILD skills...

I'm the maintainer of the upstream so I am keeping the PKGBUILD sync with the upstream. But adding PGP integrity is something I have to consider.

@dreieck: No, this is not a misnamed VCS package, despite the appearances (although it used to be). Note that prepare() does git checkout v$pkgver, so it does in fact build the (fixed) version declared in the PKGBUILD.

It’s true (attn @afichet) that it’s something of an unusual way to achieve this result; a more conventional approach would be to have "$pkgname::git+https://github.com/yama-chan/$pkgname.git#tag=v$pkgver" in the source array. (Personally, I would reference the commit hash instead to provide some degree of integrity protection from upstream retagging, and maybe also add PGP verification using ?signed and validpgpkeys because upstream signs their commits, but that’s a matter of preference.)

Also, you download some latest version from git.

So, your package should be renamed to openexr-thumbnailer-git according to the packaging guidelines. A proper provides=("openexr-thumbnailer=${pkgver}") you already have; a conflicts=("openexr-thumbnailer") should be added as well.

Also, the $pkgver should reflect any updates to the git repository -- so you should add a pkgver()-function which dynamically creates the package version -- ideally beginning with the upstream's notion (like 3.10), and then some monotoneously increasing information about the actual commit (git rev-list --count HEAD e.g., maybe adding latest commit date and short hash if wanted).

Thanks for maintaining!

Fails to build for me with a similar error as gthumb-openexr-extension does -- maybe also here the correct openexr-dependency must be 'openexr<3' 'openexr>=2"? (see → this comment from 2021-05-03 for gthumb-openexr-extension):

==> Starting build()...
-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found OpenEXR: OPENEXR_HALF_LIBRARY-NOTFOUND;/usr/lib/libIex.so;OPENEXR_ILMIMF_LIBRARY-NOTFOUND;/usr/lib/libIlmThread.so;/usr/lib/libImath.so  
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.7.3") 
-- Checking for module 'gio-2.0'
--   Found gio-2.0, version 2.68.1
-- Checking for module 'gdk-pixbuf-2.0'
--   Found gdk-pixbuf-2.0, version 2.42.6
-- Configuring done
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
OPENEXR_HALF_LIBRARY
    linked by target "openexr-thumbnailer" in directory /[...]/openexr-thumbnailer/src/openexr-thumbnailer
OPENEXR_ILMIMF_LIBRARY
    linked by target "openexr-thumbnailer" in directory /[...]/openexr-thumbnailer/src/openexr-thumbnailer

-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.
==> ERROR: A failure occurred in build().
    Aborting...

Thanks for maintaining!

Thanks for your valuable feedback :-) Now, specifically checking out v$pkgver tag. Much better like that indeed.

OK, I tried to fix the PKGBUILD, but then discovered that the sources don't build at all for me due to an upstream bug. Waiting for resolution on afichet/openexr-thumbnailer#3 for now, and I'll be back with the PKGBUILD.

The package does not build in a clean chroot:

ERROR: Cannot find the git package needed to handle git sources.

Please add git to makedepends.

It would be nice if you also renamed the package to something like openexr-thumbnailer-git, because tools for AUR autoupdates like aurto usually use the package name to determine if it is a VCS package (and so should be updated even if there are no changes to the PKGBUILD). Including a pkgver() function to dynamically construct the package version depending on e.g. the output of git describe will also probably help reduce confusion (the tool can then detect if a rebuild changed the package contents). There are more details on VCS packages on the wiki, but in broad terms that’s it.