Dear Maintainer,

"important" because reportbug's prompt says "a bug which has a major
effect on the usability of a package."  Not "grave" because while
completely unusable on this arch, I don't think "most or all users"
are actually doing anything on ppc64.  If that needs adjustment due to
the unreleased architecture, I'm totally fine with that.

   * What led up to the situation?

I was actually trying to run restic (backup software package) on this
platform.  Instead of filing a bug on that package, I figured I might
try seeing if the golang toolchain works at all.  As far as I can tell,
all go binaries on ppc64 fail immediately with a SIGILL.  This includes
the compiler/linker/standard library package for which this bug report
is being submitted.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Installed restic.  Tried running restic.  Immediate failures as above.
Installed golang-1.26, tried building Hello World code from
https://go.dev/doc/tutorial/getting-started.  Same result:

$ hostname; date; arch; cat /etc/debian_version; /usr/lib/go-1.26/bin/go --help; /usr/lib/go-1.26/bin/go --version
stretch
Sun Apr 26 05:19:15 PM UTC 2026
ppc64
forky/sid
Illegal instruction        /usr/lib/go-1.26/bin/go --help
Illegal instruction        /usr/lib/go-1.26/bin/go --version
$

   * What was the outcome of this action?

$ hostname; date; arch; cat /etc/debian_version; /usr/lib/go-1.26/bin/go --help; /usr/lib/go-1.26/bin/go --version
stretch
Sun Apr 26 05:19:15 PM UTC 2026
ppc64
forky/sid
Illegal instruction        /usr/lib/go-1.26/bin/go --help
Illegal instruction        /usr/lib/go-1.26/bin/go --version
$
   * What outcome did you expect instead?

I would expect that a compiler package for ppc64 would be able to at
least print command line help text and its embedded version information.
Even better would be to compile the example code found on the go.dev
web site.  And even better than that would be that application code
(prevoisly mentioned restic package) built with the toolchain be able
to run.

Unfortunately, your intuition was exactly correct - this machine isn't
supported by the upstream Go protect for quite a few years now:

https://go.dev/wiki/MinimumRequirements#ppc64-big-endian

❤️,
- Tianon

Tianon Gravi writes:

I am not shocked.  But at the same time, it does not really address
the bug in the package: The Golang toolchain package is available in
the archive, is installable, configures successfully, but does not
(can not possibly) run.

I imagine similar circumstances have come up on other
less-than-mainstream architectures.  And even in the Wintel space,
there are some who'd like to obsolete older hardware.  Are there any
precendents that would provide guidance in this area?  (And, yes,
niche hardware...  Just reporting a package issue.  I'm not expecting
anyone to spend weeks reviving code that upstream has deemed obsolete
years ago.  Just... it should maybe not install successfully if it
can't run on the OS/hardware installing it?  And perhaps the same for
binary packages that are built with it?)

Thanks for the prompt response and pointer to upstream's docs!

- Aaron

I agree that it's a less-than-ideal situation, but unfortunately, I
don't see much we can do about it -- this is kind of just how APT
works, so it's an unfortunate side effect of having a higher
"baseline" in Go than Debian itself has.  The only "fix" I can imagine
is removing support for ppc64 entirely, which seems like a net loss
IMO, but I admit I don't have any experience at all with ppc64
machines (only ppc64le).

Debian *does* contain
https://packages.debian.org/source/sid/isa-support, but it doesn't
have any binary packages that help here, and it's kind of a hack
around APT's lack of support for something like this to begin with.
Then we'd have to *also* inject that dep into every ppc64 build
downstream of Go, which is non-trivial.

♥,
- Tianon

Tianon Gravi writes:

That does seem like overkill.  And would at the same time keep POWER 8
big endian machines from having the Go toolchain and any software
written in that language.

Maybe that is the best way forward here?  Would be ugly for sure.
Lots of wishlist bugs.  179 source packages to file against...
*cries*

Didn't say it was simple.  Just that "it installs, but cannot be run"
is a bug.  And (probably unfortunately) it meets the definition of
"important" at https://www.debian.org/Bugs/Developer and in
reportbug's prompts.  (Unless there is a thing that says "non release
architecture bugs can't be important" that I have not seen.)

I'll do some real life conversations with people (Debian folk and
others interested in odd hardware) this week and share any brilliant
suggestions that come back to me.

Thanks for your detailed responses!

- Aaron