What I could do is run gccgo on amd64, but I don’t expect that to turn up many issues. If you’re interested, let me know, and I might be able to do that this weekend.
On Wed, Feb 28, 2018 at 9:04 AM, Michael Stapelberg <stapelb...@debian.org> wrote: > Actually, thinking about it, the CI results will not be representative in > this case, as they use golang-go on amd64 only. > > If you wanted to do a somewhat quick test of the entire archive on a > specific architecture, you could replicate the setup described at > https://pkg-go.alioth.debian.org/ci.html (tl;dr: create a gopath using > pgt-gopath, run ci-build). I don’t have sufficient access to non-amd64 > machines to do it myself. > > On Wed, Feb 28, 2018 at 8:24 AM, Michael Stapelberg <stapelb...@debian.org > > wrote: > >> As mentioned on IRC: >> >> 08:18 @sECuRE> cbmuser: yeah, replacing golang-go with golang-any should >> do the trick >> 08:19 @sECuRE> cbmuser: in fact, after the migration of our repos to >> salsa (a matter of a small number of weeks at this point), i >> think we can trivially update all repos, wait for the CI >> results to trickle in, and upload the updated packages >> >> Do note that making packages available on more architectures exposes more >> portability issues, so increases our workload. >> >> It would be a nice gesture if you (or someone?) could volunteer to field >> and fix these portability issues as they arise, at least for the transition >> period, to help smooth out the increased workload. >> >> On Wed, Feb 28, 2018 at 1:24 AM, John Paul Adrian Glaubitz < >> glaub...@physik.fu-berlin.de> wrote: >> >>> Dear Debian Go Packaging Team! >>> >>> Some time ago, I had a discussion with Ian Lance Taylor from Go upstream >>> regarding the state of gccgo as compared to golang-go. >>> >>> According to Ian, gccgo should be able to build any package without >>> problems >>> that builds with golang-go. Any package that does not build fine with >>> gccgo >>> is considered to be a bug in gccgo and should be reported upstream. >>> >>> To test the validity of this statement, I picked a number of packages >>> from >>> your package list which have "golang-go" in their Build-Depends and >>> replaced >>> "golang-go" with "golang-any" and tried to test build the packages on a >>> powerpc porterbox - an architecture which doesn't have a golang-go port. >>> >>> The following packages were tested: >>> >>> * golang-glide >>> * gocode >>> * codesearch >>> * golang-petname >>> * gopass >>> * golang-golang-x-exp >>> * snapd >>> >>> Out of these 7 packages, 5 packages built fine. Both golang-golang-x-exp >>> and snapd didn't built because they had additional build dependencies >>> which >>> could not be fulfilled. >>> >>> However, I think this quick test shows that chances are pretty high that >>> a large number of golang-go-any packages will build fine with gccgo on >>> architectures like powerpc and sparc64. >>> >>> Thus, I would like to ask to replace "golang-go" in the Build-Depends for >>> all Go packages which are maintained by the Debian Go Packaging Team. >>> >>> Would that be possible? Would be awesome to raise the number of available >>> packages on Debian Ports architectures :-). >>> >>> Thanks, >>> Adrian >>> >>> -- >>> .''`. John Paul Adrian Glaubitz >>> : :' : Debian Developer - glaub...@debian.org >>> `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de >>> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >>> >>> _______________________________________________ >>> Pkg-go-maintainers mailing list >>> Pkg-go-maintainers@lists.alioth.debian.org >>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg- >>> go-maintainers >>> >> >> >> >> -- >> Best regards, >> Michael >> > > > > -- > Best regards, > Michael > -- Best regards, Michael
_______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers