Package Details: hdrview-git 2.0.1+3.r339.20241220.2902140-4

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: afnan (dreieck)
Last Packager: dreieck
Votes: 0
Popularity: 0.000000
First Submitted: 2019-03-29 04:28 (UTC)
Last Updated: 2024-12-20 12:29 (UTC)

Latest Comments

1 2 Next › Last »

dreieck commented on 2024-12-20 12:31 (UTC) (edited on 2024-12-20 12:31 (UTC) by dreieck)

Note:

  • Currently broken!, upstream installs executable to /usr/HDRview. Moving it to /usr/bin/HDRview results in segmentation fault since it does not find anymore the assets at /usr/assets/. Otherwise, setting -DCMAKE_INSTALL_PREFIX=/usr/bin must also not be done because otherwise fonts and images end up in /usr/bin/. See https://github.com/wkjarosz/hdrview/issues/130.
  • If upstream does not fix it, change to installation into /opt/hdrview/, but for now, await reactions of upstream.

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

dreieck commented on 2023-01-05 20:47 (UTC)

Upstream has moved. New location:

See → this comment

Also, the license must be installed since it is not a common Arch Linux license, and libglvnd and hicolor-icon-theme are missing dependencies.

Please update your PKGBUILD.

Also, you miss conflicts=('hdrview').

I have also done some → other modifications to the PKGBUILD, feel free to adopt whatever you like from → this new one:

# Maintainer: Afnan Enayet <afnan at afnan.io>

_pkgname=hdrview
pkgname="${_pkgname}-git"
pkgver=1.7.1.r312.20230104.b6f0ce5
pkgrel=1
pkgdesc='A simple research-oriented high-dynamic range image viewer with an emphasis on examining and comparing images, and including minimalistic tonemapping capabilities'
url='https://github.com/wkjarosz/hdrview'
arch=(
  'x86_64'
  'i686'
)
license=('BSD')
provides=(
  "${_pkgname}=${pkgver}"
)
conflicts=(
  "${_pkgname}"
)
makedepends=(
  'cmake'
  'git'
)
depends=(
  'hicolor-icon-theme'
  'libglvnd'
  'zlib'
)
source=(
  "${_pkgname}::git+${url}.git"
)
sha256sums=(
  'SKIP'
)

prepare() {
    cd "${srcdir}/${_pkgname}"

    # The preferred method of working with submodules in the AUR guidelines
    # doesn't seem to work recursively, so we use the "naive" method instead
    git submodule update --init --recursive

    mkdir -p build
    cd build
    # Run cmake in `prepare()` since it will download stuff.
    cmake \
      -DCMAKE_INSTALL_PREFIX=/usr \
      -DCMAKE_BUILD_TYPE=Release \
      -DDOCS=ON \
      -DFETCHCONTENT_QUIET=OFF \
      -DIMATH_ENABLE_LARGE_STACK=ON \
      -DIMATH_HALF_USE_LOOKUP_TABLE=ON \
      -DIMATH_INSTALL_PKG_CONFIG=OFF \
      -DIMATH_INSTALL_SYM_LINK=OFF \
      -DNANOGUI_BUILD_GLFW=ON \
      -DOPENEXR_INSTALL=OFF \
      -DOPENEXR_INSTALL_PKG_CONFIG=OFF \
      -DOPENEXR_INSTALL_TOOLS=OFF \
      ..
}

pkgver() {
    cd "${srcdir}/${_pkgname}"

    _ver="$(git describe  --tags | sed -E 's|-g[0-9a-fA-F]*$||' | sed -E 's|^[vV]||' | tr '-' '+')"
    _rev="$(git rev-list --count HEAD)"
    _date="$(git log -1 --date=format:"%Y%m%d" --format="%ad")"
    _hash="$(git rev-parse --short HEAD)"

    if [ -z "${_ver}" ]; then
        error "Version could not be determined."
    return 1
    else
        printf '%s' "${_ver}.r${_rev}.${_date}.${_hash}"
    fi
}

build() {
    cd "${srcdir}/${_pkgname}/build"

    make -j"$(nproc)"
}

package() {
    cd "${srcdir}/${_pkgname}"

    make -C "${srcdir}/${_pkgname}/build" DESTDIR="${pkgdir}/" install

    # Add a lowercase executable symlink
    ln -svr "${pkgdir}/usr/bin/HDRView" "${pkgdir}/usr/bin/hdrview"

    # Project installs a copy of its own deps as well. Fixup.
    for dep in Imath OpenEXR
    do
      rm -rf "$pkgdir/usr/include/$dep"/
      rm -rf "$pkgdir/usr/lib/cmake/$dep"/
      rm -f  "$pkgdir/usr/lib/pkgconfig/$dep.pc"
    done

    # These don't have a filename trivially derived from the dep name, but
    # the project doesn't have any static lib of its own so let's just
    # blindly remove any.
    rm -f "$pkgdir"/usr/lib/lib*.a

    # Raise an error in case there's every anything else added (either
    # a new dep, or the project starts shipping libs)
    if [ -d "$pkgdir"/usr/include/ ]; then
      rmdir "$pkgdir"/usr/include/
    fi
    if [ -d "$pkgdir"/usr/lib/cmake/ ]; then
      rmdir "$pkgdir"/usr/lib/cmake/
    fi
    if [ -d "$pkgdir"/usr/lib/pkgconfig/ ]; then
      rmdir "$pkgdir"/usr/lib/pkgconfig/
    fi
    if [ -d "$pkgdir"/usr/lib/ ]; then
      rmdir "$pkgdir"/usr/lib/
    fi

    for _docfile in README.md TODO.md; do
      install -D -m644 -v "${_docfile}" "${pkgdir}/usr/share/doc/${_pkgname}/${_docfile}"
    done
    install -D -m644 -v LICENSE.txt "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE.txt"
}

Thanks for maintaining!