[pkg-golang-devel] src:golang-1.7 and s390x

[Aurelien Jarno]

On 2016-10-04 16:36, Philipp Kern wrote:
> Hi,
> 
> On 10/04/2016 03:03 PM, Tianon Gravi wrote:
> > We've got a bit of a dilemma with respect to src:golang-1.7 and s390x
> > support. :)
> > 
> > Go 1.7 finally added official support for s390x, but it's z196+ only
> > (no z10 support either currently or in the works [0]).  As it stands
> > today, there are three s390x buildds and only "zandonai" fits Go's
> > requirements.
> > 
> > [0]: https://github.com/golang/go/issues/16637
> > 
> > The first few times we uploaded, we got lucky and were built on
> > zandonai, but this most recent time we hit zemlinsky and the package
> > tests failed with "Illegal instruction" (not unexpectedly) [1].
> > 
> > [1]: https://buildd.debian.org/status/logs.php?pkg=golang-1.7&arch=s390x
> > 
> > Is there something we could add to the package metadata or similar to
> > make sure it's assigned to the correct buildd? (and to inform users of
> > the s390x package what the minimum requirements are?)
> > 
> > If I'm asking the wrong group, please do let me know and I'm happy to
> > redirect! (figured I'd start here given the note in the buildd.d.o
> > footer about "Architecture specific issues" O:) )
> 
> that's a pretty frustrating request in a way, but of course you're the
> least responsible for the frustration here. :)
> 
> Unfortunately the blacklist is on a per-source package name basis and
> given that your source package is versioned that means that someone
> needs to update the blacklist manually on the affected buildds whenever
> a new major version of Go has been uploaded.

I guess the resulting go package will then be installed in the chroots
for building related go packages, and we'll also need to blacklist them
on the non-capable buildds.

> I did the needful on zani and zemlinsky, but it means that I need to
> even more actively pursue the replacement of these with z196+ era

I wonder if it is a good thing to do. It means we currently have only
one buildd able to build go, so we do not have any redundancy for go
related packages, and thus can't provide security support for them.

> machines. (At least) current SUSE also does not support the z10 anymore,
> so we are essentially stuck on a dinosaur. But LinuxONE might be able to

Last time I asked about bumping the ISA to at least z900 [1], it seems
even this small ISA increase  will left out a few of our users. I
therefore wonder if we should do it or not.

To come back to go, one possible way to fix that would be to patch the
existing code to not use the problematic instructions (IIRC instructions
added in recent ISAs might be a bit complex, but should not be a problem
to emulate with a few other instructions). I haven't looked at the go
code yet, so I don't know if we talk about a few instructions to patch
at a few places, or dozen of instructions to patch at dozen of places.
I will try to give a look in the next days. It might be a solution for
Stretch until we find how to get new build daemons and officially raise
the ISA.

Regards,
Aurelien

[1] https://lists.debian.org/debian-s390/2016/05/msg00008.html

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien at aurel32.net                 http://www.aurel32.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-golang-devel/attachments/20161005/8f713a03/attachment.sig>