* Package name    : loccount
  Version         : 1.2
  Upstream Author : Eric S. Raymond <esr@thyrsus.com>
* URL             : http://www.catb.org/~esr/loccount/
* License         : BSD 2-Clause
  Programming Lang: Go
  Description     : Count SLOC (source lines of code) in a source tree.

This tool counts source lines of code (SLOC) in a directory tree,
auto-detecting the language in each source file and omitting
whitespace and comments accoding to the language's syntax. It then
reports SLOC broken out by language, and a total, in either
eyeball-friendly text or JSON for postprocessing.

loccount's target audience is software developers. It is useful for
auditing code complexity growth over time, codebase size comparisons,
and defect projections. It can do COCOMO 1 cost estimation.

The design was inspired by David Wheeler's well-known 'sloccount'
tool, (which is packaged in Debian) but is more than an order of
magnitude faster and supports twice as many languages.  Unlike
sloccount it has no runtime dependencies. It has a comprehensive test
suite. It could replace sloccount, and probably should.

To my knowledge no packages rely on it.  It is well-tested, stable
code with a low release frequency

I am the author.  I am seeking a package maintainer.

Hi

I've had a good look into your request, and having known sloc in the
past as being very usefull, I thought why not jump and help.

I've check the process required, would need a sponsor, but that comes in
a bit later (Just for the actual upload once everything is ready)

I can offer the following process:-

Stage 1) Work on a script which will monitor your source repo on gitlab
(+- every 24hours), and on change, build master branch and upload to a
ftp server (My Own). I will provide link later once setup.

Stage 2) Crossbuild for all architectures and make wip available via ftp
(I can however only test x86-64, i386 and arm64), which have worked so
far just using golang compiler stuff)
This stage gives everyone envolved a chance to review/test the deb files
for any errors etc.

Stage 3) Move to autobuild on new Release Tag, I.E. You create a new
release tag, and the system builds the new release version.
(Pretesting would be done on the latest tag)

Stage 4) Upload to Debian, for final review.

Stage 5) Hand over to Incoming, and wait/bug report for an upload
sponsor to accept/comment etc.

I am new in the maintainer side, but am willing to setup, and have the
facilities to setup this build in a mostly automated fashion. I.E. I
only have to click the final submit button if everything goes to plan.

Full source of the actual script will be available once released.

Regards
Gavin Bauer