[pkg-go] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}

[Peter Colberg]

Hi Martín,

Thanks for the quick review.

On Fri, Oct 07, 2016 at 12:51:14PM +0200, Martín Ferrari wrote:
> It is indeed peculiar, and I wonder what ftp-master will think of it.
> Tracking license info for each commit could be fine, but the license
> needs to be in the repository, otherwise an exported tarball has no
> license. He could also import the license in each file if he wanted to
> make sure everyone is aware...

I am hoping that ftp-master considers a Debian source package an
inseparable unit. I will repack the orig tarballs otherwise. In the
latest version of acmetool, the upstream author has gone as far as
removing the existing license file in favour of the RILTS scheme.

https://github.com/hlandau/acme/commit/a4d55ea51a8782633d7ca477d24c5da9a5c6147b

> Comments on the package (I only checked goutils):

I applied the changes below to all three packages.

> * Replace the golang-go build-dependency with golang-any, which brings
> gccgo where golang-go is not available.

Done. To test compilation with gccgo, I temporarily replaced the build
dependency on golang-any with gccgo-6, but the build fails on amd64:

  dh build --buildsystem=golang --with=golang
     dh_testdir -O--buildsystem=golang
     dh_update_autotools_config -O--buildsystem=golang
     dh_auto_configure -O--buildsystem=golang
     dh_auto_build -O--buildsystem=golang
	  go install -v -p 1
  dh_auto_build: go install -v -p 1 failed to to execute: No such file or directory
  debian/rules:4: recipe for target 'build' failed
  make: *** [build] Error 2
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

Is this a bug in dh-golang or gccgo-6?

> * Drop the golang-go dependency in the binary package, as it is not
> really needed.

Done.

> * The description is too vague, this package is actually only useful for
> his other utilities, so I'd specify that more clearly.

Done. I extended the description to mention acmetool.

> * In debian/copyright you say it is Expat license, but then your patch
> says it is MIT.

Please take another look at upstream-license.patch: The description
does not mention MIT at all; it is only used in the upstream filename.

What is known as MIT license in the outside world, is considered
ambiguous by Debian and more precisely referred to as the Expat
license. Please see the license specification for debian/copyright:

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-specification

“There are many versions of the MIT license. Please use Expat instead, when it matches.”

> * The copyright info for clock/* does not reflect anything in the
> repository.

The author conveniently moved this to the bottom of clock/clock.go:

// © 2015 Jonathan Boulle   Apache 2.0 License

The debian/copyright stanza stems from golang-github-hlandau-degoutils, which
as mentioned in the ITP bug is the predecessor of goutils and will be removed
once the three new dependencies have been accepted. Since degoutils has been
accepted by ftp-masters before, the debian/copyright stanza should be fine.

> Seeing his replies, I am not sure it will be a pleasant upstream to work
> with :(

I was pondering seeking another maintainer or otherwise orphaning the
package when the behaviour of the maintainer was blocking an important
fix. I temporarily solved the issue by adding a patch that reverted to
the older degoutils as a build dependency, but I thought long and hard
whether it is worth it to continue maintaining acmetool.

https://bugs.debian.org/833494

Currently I believe it continues to be worth it. Apart from this one
bug, acmetool has generally required the least amount of attention of
the LE clients in Debian, since it is well designed and just works.
acmetool uses a well thought-out and documented directory schema:

https://github.com/hlandau/acme/blob/master/_doc/SCHEMA.md

Peter