I don't know what the .SlackBuild script does. There should be more information printed somewhere, showing what exactly failed. Can you find that?

Note that compress/gzip/testdata/issue6550.gz is a binary file, so please verify that it was not corrupted anywhere during the build process.

issue6550.gz is an intentionally corrupted file used in the unit tests... why does SlackBuild care about inspecting whether it is valid or not?

The google-go-lang.SlackBuild script runs /sbin/makepkg at the end.

The output as "WARNING: gzip test failed on usr/lib/go1.9/go/src/compress/gzip/testdata/issue6550.gz"
was from the makepkg script.

https://mirrors.slackware.com/slackware/slackware-14.0/source/a/pkgtools/scripts/

Index of /slackware/slackware-14.0/source/a/pkgtools/scripts

makepkg

# Warn of corrupt or empty gzip files:
find . -type f -name '*.gz' | while read file ; do
  if ! gzip -t $file 1> /dev/null 2> /dev/null ; then
    echo "WARNING:  gzip test failed on $(echo $file | cut -b3-)"
  else
    if [ "$(gzip -l $file | tail -n 1 | tr -s ' ' | cut -f 3 -d ' ')" -eq 0 ]; then
      echo "WARNING:  $(echo $file | cut -b3-) is an empty gzipped file"
    fi
  fi
done

My question is why SlackBuild cares about this at all? I don't see why some other packaging system should care about the files (especially test files) within a package. I really don't want our tests to be at the whim of whatever obscure rule package managers have.

#14937 was already a case where we had to scrub all MTIME fields from gzip files for Debian.

It was /sbin/makepkg (not the build script) that output this warning which informed what the package will contain, if the package factually is created, which it was, so I recommend closing the issue.

The script /sbin/makepkg (not the Go code) was the source of the warning.

Since this is just a warning, and I believe the correct place to fix this in makepkg, and not the Go project. Am I to correct to believe that there is nothing that we can do here?

As dsnet inferred "issue6550.gz is an intentionally corrupted file used in the unit tests...".

bash-4.2# file issue6550.gz
issue6550.gz: gzip compressed data, extra field, encrypted
bash-4.2# 

Therefore, presuming the accuracy of that quoted statement, there's nothing to fix on the makepkg end; makepkg is doing its job WARNING of zero length files and also of the corrupt gzip file.

Am I to correct to believe that there is nothing that we can do here?

bash-4.2# grep -nr 6550 gzip
gzip/gunzip_test.go:415: func TestIssue6550(t *testing.T) {
gzip/gunzip_test.go:416:     f, err := os.Open("testdata/issue6550.gz")
gzip/gunzip_test.go:422:             t.Fatalf("NewReader(testdata/issue6550.gz): %v", err)
bash-4.2#

Seems that's the case.