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.
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.
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.
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.
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
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.
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.
(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
Got it, will provide SVN diffs.
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.
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.
Also, putting ffmpeg in RUN_DEPENDS would be misleading, since loudgain doesn't require the ffmpeg binary, only the libraries.
And if required shared libraries are not registered in the pkg database, then `pkg check --dependencies` won't detect if they are missing.
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.