On 8 October 2016 at 09:46, Peter Colberg <pe...@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 > Pkgfirstname.lastname@example.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers >
_______________________________________________ Pkg-go-maintainers mailing list Pkgemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers