On 07/10/16 22:46, Peter Colberg wrote:

> 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.

Still, the problem might be that it is considered license-less, as the
files are not there in the upstream tarball. But well, ftp-master will

> 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?

No, it is that golang-any provides the symlink only on non-golang
architectures.. I don't know of any easy way to test this nowadays,
except for manyally creating a link from /usr/bin/go to gccgo-6

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

Sorry, my bad.

> 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:

OK, fair enough. I have a big backlog of stuff to do this week, but as
soon as I have a minute I will review again. Unless somebody else is
faster than me :)

Martín Ferrari (Tincho)

Pkg-go-maintainers mailing list

Reply via email to