Bug 239887 - graphics/luminance-qt5: Update to 2.6.0
Summary: graphics/luminance-qt5: Update to 2.6.0
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Alexey Dokuchaev
URL: http://qtpfsgui.sourceforge.net/?p=388
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2019-08-15 18:42 UTC by kunda
Modified: 2019-11-02 12:50 UTC (History)
3 users (show)

See Also:
h2+fbsdports: maintainer-feedback+


Attachments
Update to 2.6.0 (1.82 KB, patch)
2019-08-15 23:17 UTC, Hannes Hauswedell
h2+fbsdports: maintainer-approval+
Details | Diff
New patch (2.18 KB, patch)
2019-08-31 16:43 UTC, Hannes Hauswedell
h2+fbsdports: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description kunda 2019-08-15 18:42:30 UTC
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.
"
Comment 1 Hannes Hauswedell 2019-08-15 23:17:04 UTC
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).
Comment 2 Hannes Hauswedell 2019-08-25 21:57:09 UTC
Can someone change the state from needs-patch to has-patch or needs-qa (or what would be correct)?

Thank you!
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2019-08-26 03:45:39 UTC
@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
Comment 4 Hannes Hauswedell 2019-08-31 16:43:56 UTC
Created attachment 207048 [details]
New patch
Comment 5 Hannes Hauswedell 2019-08-31 16:49:35 UTC
> - 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.
Comment 6 Raphael Kubo da Costa freebsd_committer 2019-10-20 20:00:36 UTC
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
Comment 7 Alexey Dokuchaev freebsd_committer 2019-11-01 16:54:18 UTC
I'll take it from here, the port needs from preparation before it can be updated to the latest version.
Comment 8 Hannes Hauswedell 2019-11-02 12:50:04 UTC
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? ¯\_(ツ)_/¯