Announcement: http://qtpfsgui.sourceforge.net/?p=388 " Luminance HDR 2.6.0 is out! After almost two years of development Luminance HDR 2.6.0 is finally out. This new release introduces new features: Four brand new tone-mapping operators: ferwerda, kimkautz, lischinski and vanhateren. All tone-mapping operators have been optimized for speed and lower memory consumption (Thanks to Ingo Weyrich). Speed up for hdr creation (Also thanks to Ingo Weyrich). Added post processing gamma and saturation. In HDR Wizard it is now possible to preview the final HDR after applying different fusion settings and before accepting it. Other small improvements and bug-fixing as usual. Minimum requirement for Luminance HDR is a CPU that supports SSE2. "
Created attachment 206602 [details] Update to 2.6.0 Thanks for the notification! This patch updates the port to 2.6.0 The patches in the files directory are no longer needed for the port. While we are at it: I would propose moving the port from graphics/luminance-qt5 to graphics/luminance or better graphics/luminance-hdr (now that the -qt4 port is gone anyway).
Can someone change the state from needs-patch to has-patch or needs-qa (or what would be correct)? Thank you!
@Hannes Please: - Include the patch files / directory removals in the svn / unified diff - Create a separate issue for the port rename proposal (including patch) - Confirm the patch/changes here pass QA (portlint, poudriere at least) [1] - Set the maintainer-approval Attachment flag to signify maintainer approval on patches for ports you maintain. Attachment -> Details -> maintainer-approval [+] (or set it during initial upload/attachment) [1] https://www.freebsd.org/doc/en/books/porters-handbook/testing.html
Created attachment 207048 [details] New patch
> - Include the patch files / directory removals in the svn / unified diff Isn't that included? I removed the directory before creating the diff and the diff says: Only in luminance-qt5OLD: files > - Create a separate issue for the port rename proposal (including patch) Will do so once this is through. > - Set the maintainer-approval Attachment flag to signify maintainer approval on patches for ports you maintain. Attachment -> Details -> maintainer-approval [+] (or set it during initial upload/attachment) Done. > - Confirm the patch/changes here pass QA (portlint, poudriere at least) make describe passses. portlint passes. make check-plist passes. make stage-qa detected missing dependency on openmp. I have updated the patch for this. Now stage-qa passes. port test gives me a lot of the following: actual-package-depends: dependency on /usr/local/lib/libboost_date_time.so not registered (normal if it belongs to base) But the port has LIB_DEPENDS on libboost_date_time.so:devel/boost-libs (and other respective ports). I haven't worked with poudriere, yet, I thought that was for bulk building? Is it required for all ports maintainers to install this nowadays? It looks non-trivial to set up.
I've tried building the patch on Poudriere, and it fails on `make patch': =======================<phase: patch >============================ ===> Patching for luminance-hdr-qt5-2.6.0 ===> Applying FreeBSD patches for luminance-hdr-qt5-2.6.0 1 out of 1 hunks failed--saving rejects to src/TransplantExif/TransplantExifDialog.cpp.rej => FreeBSD patch patch-gentoo_7b52c8 failed to apply cleanly. *** Error code 1
I'll take it from here, the port needs from preparation before it can be updated to the latest version.
Thank you very much for picking this up, Alexey! I am sorry I didn't follow up on this, but as someone who maintains only few ports that rarely get updated it is increasingly difficult to keep up with procedures required to get an update merged. I responded same-day to the original user-request by supplying a patch, but the entire resulting process seems to be rather complicated for everyone. To be honest, I don't understand why I cannot fork the Ports, create a pull-request with the update and have CI run all necessary checks. That would immediately tell me what things still need fixing and would save other port maintainers from re-iterating the rules to people like me again and again. Really, it's 2019. This process is industry standard. Everyone who does anything in Open Source knows how it works. OTOH having to use five different tools to perform linting is confusing. And why do I have to self-approve my own patches when I am the maintainer? ¯\_(ツ)_/¯
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=5845c06cfb5e766eac1ad3363c31c4b2229189b0 commit 5845c06cfb5e766eac1ad3363c31c4b2229189b0 Author: Alexey Dokuchaev <danfe@FreeBSD.org> AuthorDate: 2021-05-14 18:04:48 +0000 Commit: Alexey Dokuchaev <danfe@FreeBSD.org> CommitDate: 2021-05-14 18:06:43 +0000 - Belatedly update Luminance HDR to the latest version 2.6.1.1 - Allow to build without internal help browser: it requires rather heavy QtWebEngine component which currently is also deprecated - Optionize FITS support; drop no longer needed PKGNAMESUFFIX and CONFLICTS_INSTALL knobs PR: 239887 graphics/luminance-qt5/Makefile | 42 +++++++++++------- graphics/luminance-qt5/distinfo | 6 +-- .../luminance-qt5/files/patch-CMakeLists.txt (new) | 19 ++++++++ .../luminance-qt5/files/patch-gentoo_7b52c8 (gone) | 26 ----------- .../files/patch-src_CMakeLists.txt (new) | 12 ++++++ .../files/patch-src_Exif_ExifOperations.cpp (gone) | 11 ----- .../patch-src_MainWindow_MainWindow.cpp (new) | 50 ++++++++++++++++++++++ .../files/patch-src_MainWindow_MainWindow.h (new) | 22 ++++++++++ .../files/patch-src_UI_CMakeLists.txt (new) | 19 ++++++++ graphics/luminance-qt5/pkg-plist | 4 +- 10 files changed, 154 insertions(+), 57 deletions(-)
Port had been finally updated to version 2.6.1.1, sorry for delay.