Package Details: hdrview-git 2.1.0+22.r441.20250118.8430cb3-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: dreieck
Last Packager: dreieck
Votes: 0
Popularity: 0.000000
First Submitted: 2019-03-29 04:28 (UTC)
Last Updated: 2025-01-19 13:59 (UTC)

Dependencies (31)

Required by (0)

Sources (1)

Latest Comments

1 2 Next › Last »

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 :)

1ace commented on 2023-01-07 23:26 (UTC)

@dreieck: actually, I decided to do it tonight ^^
I disagreed with a few of your suggestions so I didn't integrate them, but I'm open to discuss them if you want.
Let me know if there's anything more that you think should be done :)

dreieck commented on 2023-01-07 23:21 (UTC) (edited on 2023-01-07 23:21 (UTC) by dreieck)

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.

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

Regards!

dreieck commented on 2023-01-07 23:16 (UTC)

@1ace: 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?

1ace commented on 2023-01-07 22:29 (UTC)

@dreieck: thanks for the notes! I just did the minimal update to get things to work, but I'll have a look at your suggestions when I have some time (hopefully tomorrow) and integrate them

1 2 Next › Last »