PR mentions a fork at https://github.com/Clockwork6400/kanatest

This diff puts WWW back to original url https://kanatest.sourceforge.io/ with develpment stoped at 2018-xx-xx: version 0.4.10.
(Changelog: https://sourceforge.net/p/kanatest/code/ci/master/tree/ChangeLog)

From where 0.4.10.g20200611 comes from and why are we reviving a port with upstream dead?

In D38519#877023, @eduardo wrote:

PR mentions a fork at https://github.com/Clockwork6400/kanatest

This diff puts WWW back to original url https://kanatest.sourceforge.io/ with develpment stoped at 2018-xx-xx: version 0.4.10.
(Changelog: https://sourceforge.net/p/kanatest/code/ci/master/tree/ChangeLog)

From where 0.4.10.g20200611 comes from and why are we reviving a port with upstream dead?

The submitter has taken the last commit from the repository I use as the upstream, did some unknown modifications (supposedly portability fixes) to it and then uploaded it to github. The repository used by the submitter does not preserve any history or metadata and is not meant to be a fork, merely a rehost due to the difficulty in obtaining the state of the upstream before it was discontinued. In communication with the submitter I had modified and fixed his patch to ensure that it builds and that the official upstream is used instead of the submitter's rehosted version.

The version number follows Porter's Handbook § 5.4.3 Ex. 18 and 19, indicating “a version before the unreleased 0.4.10 taken from a git commit dated 2020-06-11.” This is as I understood general policy for generating version numbers that are taken from a git commit. The port was revived because the submitter believed it to be useful and agreed to maintain it.

The version number follows Porter's Handbook § 5.4.3 Ex. 18 and 19, indicating “a version before the unreleased 0.4.10 taken from a git commit dated 2020-06-11.” This is as I understood general policy for generating version numbers that are taken from a git commit. The port was revived because the submitter believed it to be useful and agreed to maintain it.

OK, I found that commit (g20200611) at https://sourceforge.net/p/kanatest/code/ci/860e790a35f547cc96669f805d371a5ba3d8daff/

• Build (stage) fails with NLS=OFF

I remember having same problem when gettext not present: NLS_USES= gettext

Making install in po
gmake[2]: Entering directory '/wrkdirs/usr/ports/games/kanatest/work/kanatest-0.4.10.g20200611/po'
gmake[3]: Entering directory '/wrkdirs/usr/ports/games/kanatest/work/kanatest-0.4.10.g20200611/po'
gmake[3]: Nothing to be done for 'install-exec-am'.
/bin/sh: msgfmt: not found
(...)
for i in de.mo el.mo es.mo fi.mo fr.mo hr.mo hu.mo it.mo pl.mo pt.mo ru.mo zh_CN.mo; do \
        lang=`echo $i | sed 's/\.mo$//'`; \
        /bin/sh /wrkdirs/usr/ports/games/kanatest/work/kanatest-0.4.10.g20200611/install-sh -d /wrkdirs/usr/ports/games/kanatest/work/stage/usr/local/share/locale/$lang/LC_MESSAGES; \
        install  -m 0644 $i /wrkdirs/usr/ports/games/kanatest/work/stage/usr/local/share/locale/$lang/LC_MESSAGES/kanatest.mo; \
done
install: de.mo: No such file or directory
(...)

• pkg-plist should be sorted alphabetically:

bin/kanatest
share/applications/...
share/icons/hicolor/...
%%NLS%%share/locale/...
share/pixmaps/kanatest.png

In D38519#877035, @fuz_fuz.su wrote:

Build (stage) fails with NLS=OFF

I think it's best to just remove the NLS knob entirely at this point. Clearly the package does not have support for building without NLS support.

pkg-plist should be sorted alphabetically

It is sorted mostly alphabetically, but taking the % signs into account. Will try to adjust the sort as per your guidance.

It still take some advantage of NLS by installing or not %%NLS%% files in pkg-plist but gettext must be included in USES and NLS_USES= gettext removed.