Package Details: hdrview-git 2.6.0+91.r825.20251210.f9f6e34-1

Git Clone URL: https://aur.archlinux.org/hdrview-git.git (read-only, click to copy)
Package Base: hdrview-git
Description: High dynamic range (HDR) image viewer and comparison tool
Upstream URL: https://github.com/wkjarosz/hdrview
Keywords: exr hdr image viewer
Licenses: BSD-3-Clause
Conflicts: hdrview
Provides: hdrview
Submitter: afnan
Maintainer: None
Last Packager: dreieck
Votes: 0
Popularity: 0.000000
First Submitted: 2019-03-29 04:28 (UTC)
Last Updated: 2025-12-10 23:44 (UTC)

Dependencies (47)

Required by (0)

Sources (1)

Latest Comments

1 2 Next › Last »

dreieck commented on 2026-01-01 19:18 (UTC)

Upstream just changes too much stuff in confusing ways (and downloading it's own sources of dependencies instead of using system installed).

I give up on this and orphan this package.

Please anyone who wants to deal with it, adapt.

Current cmake error: 

[...]
[7/7] Completed 'jxl-populate'
-- CMAKE_SYSTEM_PROCESSOR is x86_64
-- Compiled IDs C:GNU, C++:GNU
-- Disabled AVX512_ZEN4 (set JPEGXL_ENABLE_AVX512_ZEN4 to enable it)
-- Found Brotli: /usr/include
-- Building with JPEGXL_VERSION=794a5dcf (auto-updated)
-- Building tools: 
-- Will build JPEG-XL library
-- Disabled warnings for jxl (actual target: jxl)
-- Disabled warnings for jxl_dec (actual target: jxl_dec)
-- Disabled warnings for jxl_threads (actual target: jxl_threads)
-- Disabled warnings for jxl_dec-obj (actual target: jxl_dec-obj)
-- Disabled warnings for jxl_enc-obj (actual target: jxl_enc-obj)
-- Disabled warnings for jxl_dec-internal (actual target: jxl_dec-internal)
-- Disabled warnings for jxl-internal (actual target: jxl-internal)
-- Disabled warnings for jxl_cms (actual target: jxl_cms)
-- Disabled warnings for enc_fast_lossless (actual target: enc_fast_lossless)
CMake Error at CMakeLists.txt:248 (target_compile_options):
  target_compile_options may only set INTERFACE properties on INTERFACE
  targets
Call Stack (most recent call first):
  CMakeLists.txt:824 (disable_target_warnings)

Regards!

dreieck commented on 2025-08-25 11:10 (UTC)

Current build errors are fixed by now.

muziknavi commented on 2025-07-24 19:17 (UTC)

I get this error:

CMake Error at CMakeLists.txt:435 (message): libpng not found. Please install it or turn off HDRVIEW_ENABLE_LIBPNG.

though I have libpng installed:

pacman -Q libpng libpng 1.6.50-1

Where could be a problem?

dreieck commented on 2025-01-12 00:20 (UTC)

Fixed the package.

1ace commented on 2023-03-01 13:21 (UTC)

@dreieck: about upstream not being good with version numbers and going "back in time": that's what epoch is for, and we'll just bump it every time upstream does something like that :)

about putting the initial cmake call in prepare(), I don't remember why I didn't do that before, but your argument is valid so I just made that change :)

dreieck commented on 2023-01-13 16:46 (UTC) (edited on 2023-01-13 16:46 (UTC) by dreieck)

I see that your current PKGBUILD fetches some stuff during build(). I think that build() and package() must not assume internet connection to be present, that's why I have moved the cmake call to prepare(), to have all download be finished after prepare() and then the sources are properly set up for package building.

What was your objection against putting the cmake call into prepare()?

Regards!

==> Starting build()...
[...]
[1/9] Performing download step (download, verify and extract) for 'nlohmann_json-populate'
-- Downloading...
   dst='/home/[...]/.cache/yay/hdrview-git/src/build/_deps/nlohmann_json-subbuild/nlohmann_json-populate-prefix/src/include.zip'
   timeout='none'
   inactivity timeout='none'
-- Using src='https://github.com/nlohmann/json/releases/download/v3.9.1/include.zip'
-- [download 1% complete]
-- [download 2% complete]
-- [download 3% complete]
-- [download 4% complete]
[...]

dreieck commented on 2023-01-09 22:15 (UTC) (edited on 2023-01-09 22:17 (UTC) by dreieck)

Ahoj,

I usually add people who contribute in the comments [...]

*Check*.

And just a note, to learn: describe --tags --abbrev=10 as pkgver() is not enough, since $pkgver must be increasing with every upstream commit in -git packages, which your variant does not guarantee. Thats why appending something like r<commit_count> to the version number is one variant to make that work.

I don't see how the value could somehow not increase; do you have an example of a situation where that could happen?

Hm, if I remember correctly when I was writing my comment the pkgver() was still simpler, or I was just simply "blind". OK, now the part which leads to the current +1 in the $pkgver should guarantee an increase after every upstream commit, as long as upstream stays strict with tagging each commit according to the current tagging scheme. (I have seen packages where upstream did not live up to that, though.)

Also note that according to the VCS packaging guidelines, a leading v or V before the upstream version number should be stripped off.

Note the sed after git describe :)

Same as above: Maybe it was missing at first, or I was blind.

Now that looks fine to me.

Regards!

1ace commented on 2023-01-09 20:24 (UTC)

@dreieck: oh sorry, I just realized that while I was writing my comment yesterday you posted some of your own ^^'

You now made me co-maintainer, are you OK when I just upload my PKGBUILD, or do you want to do what you fint suiting?

I usually add people who contribute in the comments as I believe in group maintainership, and if someone tries to do something bad it's easy enough to remove them and revert the changes ^^
Please don't simply overwrite the PKGBUILD with yours, but if you want to make targetted changes (adding missing deps, build options, etc.) that's fine; for anything bigger than that it's best to discuss here first :)

And just a note, to learn: describe --tags --abbrev=10 as pkgver() is not enough, since $pkgver must be increasing with every upstream commit in -git packages, which your variant does not guarantee. Thats why appending something like r<commit_count> to the version number is one variant to make that work.

I don't see how the value could somehow not increase; do you have an example of a situation where that could happen?

Also note that according to the VCS packaging guidelines, a leading v or V before the upstream version number should be stripped off.

Note the sed after git describe :)

1 2 Next › Last »