[pkg-go] Switching build-dependencies from golang-go to golang-any

[Michael Stapelberg]

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 <stapelberg at 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 <stapelberg at 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 <
>> glaubitz at 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 - glaubitz at debian.org
>>> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>>>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>>>
>>> _______________________________________________
>>> Pkg-go-maintainers mailing list
>>> Pkg-go-maintainers at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20180228/709a2e89/attachment-0001.html>