Bug 248668

Summary: [NEW PORT] audio/loudgain: ReplayGain 2.0 loudness normalizer
Product: Ports & Packages Reporter: Cluboq <clubok>
Component: Individual Port(s)Assignee: freebsd-ports-bugs (Nobody) <ports-bugs>
Status: Closed Feedback Timeout    
Severity: Affects Only Me CC: clubok, crees, daniel.engberg.lists
Priority: --- Keywords: feature, needs-patch, needs-qa
Version: LatestFlags: clubok: maintainer-feedback? (clubok)
Hardware: Any   
OS: Any   
URL: https://github.com/Moonbase59/loudgain
Description Flags
loudgain port skeleton
loudgain port skeleton with gunk removal moved to post-extract target none

Description Cluboq 2020-08-15 09:46:05 UTC
Created attachment 217228 [details]
loudgain port skeleton

loudgain is a versatile ReplayGain 2.0 loudness normalizer, based on the
EBU R128/ITU BS.1770 standard (-18 LUFS) and supports
FLAC/Ogg/MP2/MP3/MP4/M4A/ALAC/Opus/ASF/WMA/WAV/WavPack/AIFF/APE audio files.
It uses the well-known mp3gain commandline syntax but will never modify the
actual audio data.

WWW: https://github.com/Moonbase59/loudgain

Built and run successfully on FreeBSD 11.4-RELEASE-p2 amd64, all dependencies built and installed from source by the Ports system, all being latest versions.

The latest portlint's check result: "looks fine".

If accepted, this is going to be AFAIK the only non-destructive audio normalizer in the Ports tree that can do Opus files.

Note: the upstream GitHub repo currently includes static Linux binary and a .deb package of loudgain in the release tag, which increase the tarball to 26 Mbytes (otherwise the distfile size would have been a lot smaller). Those files are deleted by the post-patch target. Upstream promises to deal with the issue eventually: https://github.com/Moonbase59/loudgain/issues/12
Hope that won't be a showstopper.
Comment 1 Cluboq 2020-08-15 09:55:58 UTC
Created attachment 217229 [details]
loudgain port skeleton with gunk removal moved to post-extract target

Moved binary gunk removal to post-extract. The earlier, the better. Unfortunately, couldn't find anything like .gitignore facility in the Ports system.
Comment 2 daniel.engberg.lists 2020-08-15 10:13:47 UTC
I did some work on this earlier but didn't submit as upstream is dead/unresponsive/no longer interested.

You need to use master branch, we have taglib 1.12b1 in tree which release version of loudgain doesn't support, at least not fully.

All PRs should be added (merged) as some also includes compilation fixes for FreeBSD, on top of that you should use shebangfix for python scripts.
I would also imagine that you need to use USES= localbase for it to properly pick up dependencies.

none@FreeBSD.org as maintainer isn't correct, please set yourself as maintainer.

I'm quite sure you dont need to set multiple dependencies for the same port (ffmpeg in this case) unless you can disable required functionality which isn't true in this case as far as I can tell.

Best regards,
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2020-08-15 10:21:19 UTC
Thank you for submitting a new port! Could you please:

- Update the attachment format to a unified diff against the ports tree root
- Confirm the changes pass QA (portlint, poudriere in particular)
- Update per review items in comment 2

Comment 4 Cluboq 2020-08-15 11:58:03 UTC
I am not using shebangfix because I don't include Python scripts in the installation. The reason: they rely on a publicly unavailable tool (bpm-calc) as a runtime dependency.

As for multiple library dependencies provided by the same port, what if they are made into separate ports sometime? Being a new to the Ports and packages frameworks, I am unsure if all the required shared libraries will land in pkg database unless I explicitly state them in the port skeleton.

The rest of the points are clear to me.
Comment 5 Cluboq 2020-08-15 12:05:31 UTC
Also, the Porter's Handbook says .shar submissions are allowed. Those are certainly easier on submitters but harder on committers. Smells of newbie hazing, but I'll do the dance.
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2020-08-15 12:20:57 UTC
(In reply to Cluboq from comment #5)

shar's are ok, but diffs are (increasingly) preferred, and get our contributors more familiar with more of our development processes much earlier. It also reduces fragmentation/special casing.

One bonus benefit for new ports is contributors can include the part of the change that adds the port to the relevant category/Makefile 

During periods where we transition between multiple defacto standards (shar/diff -> diff for example), there's always a period of lets call it gentle encouragement

Certainly not aiming to haze, we don't do that here :)

Thanks again for submitting a new port
Comment 7 Cluboq 2020-08-15 12:31:07 UTC
Got it, will provide SVN diffs.
Comment 8 daniel.engberg.lists 2020-08-15 12:36:14 UTC
As for the ffmpeg deps question, if that happens at somepoint there will be a tree-wide PR about it.

As for reference: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/uses-python.html

https://github.com/Moonbase59/loudgain/blob/master/bin/rgbpm2 Why is that not possible to include? I agree although that naming is a bit weird haivng in mind what it actually does.
Comment 9 Cluboq 2020-08-15 12:51:55 UTC
You are right about rgpbm2, it contains no mention of the bpm-calc publicly unavailable tool. In fact, it does nothing BPM-related whatsoever. I have a good mind to put it in the examples directory, after shebangfix, of course, and, perhaps rename it.

The upstream communicated with me this spring, and wrote he would have the rgbpm script as an example.
Comment 10 Cluboq 2020-08-15 12:54:06 UTC
Also, putting ffmpeg in RUN_DEPENDS would be misleading, since loudgain doesn't require the ffmpeg binary, only the libraries.
Comment 11 Cluboq 2020-08-15 13:03:38 UTC
And if required shared libraries are not registered in the pkg database, then `pkg check --dependencies` won't detect if they are missing.
Comment 12 daniel.engberg.lists 2020-08-16 18:40:21 UTC
If you want to list all deps there's nothing stopping you but be aware that it's not common practice. I think we've covered everything so far regarding this port.
Comment 13 Chris Rees freebsd_committer 2021-03-03 11:43:17 UTC
Please do feel free to reopen once the issues in comment 2 are fixed.

Shars are fine, but unlike diffs you can't view them in the browser, which makes reviewing them a pain for us.  Using shars dates back to when we used GNATS which made it really clear.