@jcajka @jchaloup just wondering whether someone from you'd like to do a quick sanity check.. as I'm not very confident in golang..

Hm, that's bad, while the build succeeds on rhel-7, it fails on fedora:
https://koji.fedoraproject.org/koji/taskinfo?taskID=31436941

Hm, that's bad, while the build succeeds on rhel-7, it fails on fedora:
https://koji.fedoraproject.org/koji/taskinfo?taskID=31436941

...because on RHEL the tests are not run at all.

Don't count of RHEL 7 to be representative of anything.

It hasn't got an up to date golang compiler for a long time (till the latest point release golang was frozen in a RHEL 7 stream), so it's been missing all the correctness fixes of recent compilers. Its go rpm macros are completely minimal and obsolete too, its Go packageset is also obsolete and full of (probably security) bugs, etc

That's what happens when RH forks Fedora, kills the EPEL link by refusing to update key packages, and then does not maintain the result for years.

So, basically, RHEL7 will let you get by with pretty much anything both Go code and Go packaging side, and help you produce broken software components.

And Fedora (rawhide) is not in a sterling set itself, it has months of fixes waiting for rh maintainers to review and merge, but it's still lights years ahead of what RHEL7 has become for Go.

@nim read my previous note, please, the SPEC is written the way that %check is not run on RHEL at all. So you could have saved your comment, unless I missed some constructive point there.

I see now that the problem is not golang version, but source-to-image of a version 1.1.13, which adds quite a lot of code into vendor/golang.org/x/sys/unix/.

@hhorak

Unit tests are the first thing that fails with a recent golang compiler that applies more correctness checks

And Fedora should have a not too obsolete golang/sys/unix that should remove the need to bundle (even though the google sys/unix code is still generated against the kernel headers of an obsolete ubuntu kernel with nothing in common with Fedora or RHEL7 kernels). The result has finally started trickling back in EL7 this fall now that the RHEL7 golang compiler lock has been removed.
https://koji.fedoraproject.org/koji/rpminfo?rpmID=15907050

So, the problems you are hitting are quite common and explained by what I wrote. But feel free to ignore me and rediscover it all yourself.

@nim ignorance was really not the intention, I appreciate your help, thanks. So now I should learn how to unbundle stuff from golang package I guess..

Assuming your upstream didn't bundle too old software versions, unbundling is just

1. rm -fr vendor/packagename
2. BuildRequires: golang(packagename)

If packagename is packaged in Fedora.

So, probably not all the stuff your package needs, since its uses parts of docker, and docker is the last thing that will be packaged sanely in Fedora, given how rotten its codebase is. But, you can probably shed many of the bundled deps, and use stuff that passed at least a few unit tests in koji.

If you feel ambitious you can package some of the missing deps, that's a good way to have their version tracked in rpm, and avoids finding too late upstream has been bundling CVE-riddled code (as long as someone bumps the Fedora packages regularly).

The compiler update, Fedora default golang compiler flags, and unbundling, tend to uncover bugs, first in unit tests, and (a bit less frequently) in the production code itself. Upstream unit testing is a lot weaker than the coverage stats people parade imply, since it tends to use a single compiler version, x86_64 only, with no hardening compiler flags, and frozen deps.

And I'd love to direct you to a clean recipe on how to do Go packages easily in Fedora, but while the latest fixes include full documentation, they won't be available until someone works on the cleanup plan. The sticking point is step 3, reviewing the fixes I wrote and prepared in the last months. Obviously, I can not review myself.

The previous attempt, currently used by Fedora, was documented in the wiki but the implementation has drifted a bit since, and I stopped updating the page, since FPC told me it was the wrong way to document things.