Re: [pkg-go] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}
On Wed, Oct 12, 2016 at 08:34:04PM +0530, Pirate Praveen wrote: > Last upload of gccgo-6 included this via alternatives. So no special > handling required. Looks much better, but it still fails (substituting gccgo-6 for golang-any): dpkg-source -b golang-github-hlandau-goutils-0.0~git20160722.0.0cdb66a dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building golang-github-hlandau-goutils using existing ./golang-github-hlandau-goutils_0.0~git20160722.0.0cdb66a.orig.tar.gz dpkg-source: info: building golang-github-hlandau-goutils in golang-github-hlandau-goutils_0.0~git20160722.0.0cdb66a-1.debian.tar.xz dpkg-source: info: building golang-github-hlandau-goutils in golang-github-hlandau-goutils_0.0~git20160722.0.0cdb66a-1.dsc debian/rules build 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 github.com/hlandau/goutils/clock github.com/hlandau/goutils/net github.com/hlandau/goutils/os github.com/hlandau/goutils/test github.com/hlandau/goutils/text github.com/hlandau/goutils/clock github.com/hlandau/goutils/net github.com/hlandau/goutils/os github.com/hlandau/goutils/test github.com/hlandau/goutils/text dh_auto_test -O--buildsystem=golang go test -v -p 1 github.com/hlandau/goutils/clock github.com/hlandau/goutils/net github.com/hlandau/goutils/os github.com/hlandau/goutils/test github.com/hlandau/goutils/text ? github.com/hlandau/goutils/clock[no test files] === RUN TestBackoff --- PASS: TestBackoff (0.00s) PASS ok github.com/hlandau/goutils/net 0.099s ? github.com/hlandau/goutils/os [no test files] ? github.com/hlandau/goutils/test [no test files] ? github.com/hlandau/goutils/text [no test files] fakeroot debian/rules binary dh binary --buildsystem=golang --with=golang dh_testroot -O--buildsystem=golang dh_prep -O--buildsystem=golang dh_auto_install -O--buildsystem=golang mkdir -p /<>/golang-github-hlandau-goutils-0.0\~git20160722.0.0cdb66a/debian/golang-github-hlandau-goutils-dev/usr/share/gocode/src/github.com/hlandau/goutils cp -r -T src/github.com/hlandau/goutils /<>/golang-github-hlandau-goutils-0.0\~git20160722.0.0cdb66a/debian/golang-github-hlandau-goutils-dev/usr/share/gocode/src/github.com/hlandau/goutils dh_installdocs -O--buildsystem=golang dh_installchangelogs -O--buildsystem=golang dh_perl -O--buildsystem=golang dh_link -O--buildsystem=golang dh_strip_nondeterminism -O--buildsystem=golang dh_compress -O--buildsystem=golang dh_fixperms -O--buildsystem=golang dh_installdeb -O--buildsystem=golang dh_golang -O--buildsystem=golang can't load package: package .: no buildable Go source files in /<> go list of dependencies failed with code 31488, at /usr/bin/dh_golang line 55. debian/rules:4: recipe for target 'binary' failed make: *** [binary] Error 123 Peter ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}
On Wed, Oct 12, 2016 at 04:54:32PM +0200, Martín Ferrari wrote: > 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 > decide. It looks like there are a few precedents in the archive: https://codesearch.debian.net/search?q=LICENSE+path%3Adebian%2Fpatches%2Flicense&perpkg=1 I have force-pushed updated master branches for each package, renaming the license file to LICENSE and stashing the changes after review so that the commit history matches the changelog. Please re-clone each package and verify the latest commit in master: e1642e6948c1afebebcb594aa1055796a8af3ffb golang-github-hlandau-goutils 278a87ca9186c43925c564be9ade82b25a12bb8a golang-github-hlandau-buildinfo 3406fc6e76a13447f87b3dbb342f1dd1e22a6dfb golang-github-hlandau-dexlogconfig > 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 :) Thanks for taking the time, your uploads will be much appreciated. Peter ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}
On 2016, ഒക്ടോബർ 12 8:24:57 PM IST, "Martín Ferrari" wrote: > >> 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 Last upload of gccgo-6 included this via alternatives. So no special handling required. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}
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. > > https://github.com/hlandau/acme/commit/a4d55ea51a8782633d7ca477d24c5da9a5c6147b 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 decide. > 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 Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}
It could (and used to be!), but alternatives are pretty terrible for toolchains/things that are often build-dependencies. Maybe we could have a gccgo-go package or something that would provide the symlink (and conflict with golang-go)? Cheers, mwh On 11 October 2016 at 11:52, Peter Colberg wrote: > On Mon, Oct 10, 2016 at 10:00:31AM +1300, Michael Hudson-Doyle wrote: > > 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. > > Do you think this can be solved by providing /usr/bin/go via alternatives? > > Peter > ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}
On Mon, Oct 10, 2016 at 10:00:31AM +1300, Michael Hudson-Doyle wrote: > 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. Do you think this can be solved by providing /usr/bin/go via alternatives? Peter ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}
On 8 October 2016 at 09:46, Peter Colberg 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@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers > ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}
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 ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
Re: [pkg-go] Sponsor uploads of golang-github-hlandau-{goutils, buildinfo, dexlogconfig}
Hi, On 07/10/16 05:37, Peter Colberg wrote: > Dear Go package team, > > Could a DD upload the following three packages to the NEW queue? > > https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hlandau-goutils.git > https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hlandau-buildinfo.git > https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-hlandau-dexlogconfig.git > Please note the peculiar form of licensing chosen by the upstream > author as described in each debian/patches/upstream-license.patch. 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... Comments on the package (I only checked goutils): * Replace the golang-go build-dependency with golang-any, which brings gccgo where golang-go is not available. * Drop the golang-go dependency in the binary package, as it is not really needed. * The description is too vague, this package is actually only useful for his other utilities, so I'd specify that more clearly. * In debian/copyright you say it is Expat license, but then your patch says it is MIT. * The copyright info for clock/* does not reflect anything in the repository. I pressume you extracted this from RILTS? > I have spent many, many issues trying to convince the author of > shipping license files alongside their software; but instead, the > author has devised a custom licensing scheme (RILTS) that places the > license file in an external repository and references it by SHA256 > hash in the commit messages of a package’s repository. Seeing his replies, I am not sure it will be a pleasant upstream to work with :( -- Martín Ferrari (Tincho) ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
