Bug#862422: [pkg-golang-devel] Bug#862422: gccgo-go: wrap gccgo-7 for full Go 1.8 runtime
Michael Hudson-Doylewrites: > Makes sense to me, I'd be happy to upload that change to experimental. Great, thanks! > What's the timeframe for gccgo-7 getting into unstable? Just waiting for > buster development to open? Presumably; I'm not aware of another reason to hold off. (An official 7.1 release recently came out, and there aren't experimental versions of binutils or glibc that could need to accompany GCC 7 to unstable.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#862422: [pkg-golang-devel] Bug#862422: gccgo-go: wrap gccgo-7 for full Go 1.8 runtime
Makes sense to me, I'd be happy to upload that change to experimental. What's the timeframe for gccgo-7 getting into unstable? Just waiting for buster development to open? On 13 May 2017 at 03:13, Aaron M. Uckowrote: > Package: gccgo-go > Version: 2:1.8~1 > Severity: important > > Could you please switch gccgo-go's 1.8 series to wrap gccgo-7 rather than > gccgo-6, so code that needs Go 1.8.x user packages but not necessarily > Google's compiler can simply Build-Depend: gccgo-any (>= 2:1.8~)? > > This change will be helpful for packaging newer upstream releases of > ncbi-entrez-direct, which have started using sort.Slice (and which will > want to go to experimental for now anyway). > > Thanks! > > -- > Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) > http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/ > finger/?a...@monk.mit.edu > > ___ > pkg-golang-devel mailing list > pkg-golang-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-golang-devel >
Bug#862422: gccgo-go: wrap gccgo-7 for full Go 1.8 runtime
Package: gccgo-go Version: 2:1.8~1 Severity: important Could you please switch gccgo-go's 1.8 series to wrap gccgo-7 rather than gccgo-6, so code that needs Go 1.8.x user packages but not necessarily Google's compiler can simply Build-Depend: gccgo-any (>= 2:1.8~)? This change will be helpful for packaging newer upstream releases of ncbi-entrez-direct, which have started using sort.Slice (and which will want to go to experimental for now anyway). Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu