Add arch buildconstraints on disk for openbsd (fixes #912)

[imsodin]

There's definitions for amd64 and 386, but nothing else on openbsd. In the version we used previously the build constraint was openbsd,amd64, now it's just openbsd. I now added build constraints for either amd64 or 386, thus "fixing" the build on arm (no functionality, but also no build failure).

[Lomanic]

👎 from me, there is nothing specific to these two archs in this file.

To fix #912, disk_openbsd_arm.go should be generated with GOOS=openbsd GOARCH=arm go tool cgo -godefs disk/types_openbsd.go > disk/disk_openbsd_arm.go (or preferably directly on an arm host).

[imsodin]

Shouldn't there still be constraints? It uses variables defined in these disk_openbsd_*arch*.go files, thus builds will fail on all archs for which no such file exists. It's much nicer to have no functionality instead of a broken build (at least for Syncthing, which does work without gopsutil).

[Lomanic]

You will still have broken functionality (broken build) if you want to call an undefined function (because of build constraints) though?

I don't have any of the armv7 boards supported by OpenBSD to generate or test everything works, it's plausible that copying the 386 definition for arm would work (cp gopsutil/disk/disk_openbsd_{386,arm}.go).

[imsodin]

That makes sense, I guess I am used to fallback stubs that just return an error when invoked. What doesn't make sense is that with the constraint on the previous gopsutil version we used (+build openbsd,amd64) we did cross-compile and publish releases for lots of arches other than amd64 on openbsd - something's fishy there. But anyway, without fallback constraints are indeed pointless - sorry for the noise and thanks for explaining ;)