Hello all. A final status update.
As already mentioned the offending ppc64el binaries was removed. (Would be great in the future if gopsutil was changed from Arch: all to the architectures where it can actually parse process information on in reality.) This bug was also lowered in severity because of the above mentioned action, to avoid this bug report from blocking testing migration. There was one final blocker, appc-spec 0.8.7 needed to enter testing first but it failed to build on s390x. I just asked for a give-back to attempt building again. It happened to build on the same buildd machine as where it last succeded on, so things should now start migrating towards testing if there isn't any other blocker I've missed. Having said that, it seems that golang upstream defines "s390 support" differently to the range of hardware supported by the Debian s390x port. Having go packages succeed to build when they happen to run on one of the newer buildds is in my opinion very unconvenient (and also ending up with SIGILL in go when appc-spec was built on zemlinsky is an RC bug in itself). I think the golang maintainers need to think a bit about which architectures (and their range of supported hardware as defined by debian architecture porters) is actually supportable. Then limit the arch field of golang (and in some cases like gopsutil maybe even further) to those architectures. Just saying "any" and relying on "when it builds it's supported" is not going to work. In other words there might be a need for a Mass-RM of golang and all rdeps on s390x (and possibly other architectures). What's said above isn't based on any real knowledge on my part only my percetion. Partially influenced by for example: https://github.com/golang/go/issues/16637 Hopefully this issue is not as bad as I fear. If it can be fixed only by tweaking the optimization flags used on certain architectures that would be awesome. I still fear the worst though. SIGILL is definitely not something we should be running into on official buildd machines atleast. Feedback appreciated. Unless someone gives me some information that changes my view on this I'll be filing an RC bug against golang about this soon (as I promised the release team member I bribed to do the give-back of appc-spec that I would do in exchange). Regards, Andreas Henriksson
