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

Sun Oct 9 21:00:31 UTC 2016

On 8 October 2016 at 09:46, Peter Colberg <peter at colberg.org> wrote:

> 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/a4d55ea51a8782633d7ca477d24c5d
> a9a5c6147b
>
> > 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?

I don't know, but it's not surprising to me. The issue that is that gccgo-6
does not install /usr/bin/go, rather it installs /usr/bin/go-6 (so you can
have gccgo-6 and golang-go both installed on systems where both are
available). When you install golang-any on a system where it brings in
gccgo-6 it installs a symlink from /usr/bin/go to go-6. This is a bit of a
pain for the reasons you've noticed, but I'm not sure what to do about it.

Cheers,
mwh

>
> > * 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
>
> _______________________________________________
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20161010/10e42f96/attachment.html>