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