https://bugzilla.redhat.com/show_bug.cgi?id=2376217
--- Comment #27 from Dave Dykstra <[email protected]> --- (In reply to Maxwell G from comment #26) > You can set GO_BUILDTAGS="<space-separated list of tags>". This doesn't work > on EPEL 8, so you can use a fallback there. On Fedora, EPEL 9, and EPEL 10 > once go-rpm-macros is updated, you can now directly pass arbitrary extra > flags to `%gobuild` (other than -tags or -ldflags which are already part of > the %gobuild definition)` such as -gcflags. Ok I switched to using the system %gobuild macro on el9 and up. I didn't yet see the ability to set -gcflags so for now I also redefine %gobuild when %go_debug is set. I wasn't able to figure out how to use it successfully with the default GO111MODULES=off so I followed what was done by forgejo and set `%global gomodulesmode GO111MODULE=on`. If I don't do that it isn't able to find the main source code module; it gets an error like this: main.go:9:2: cannot find package "github.com/openbao/openbao/command" in any of: /usr/lib/golang/src/github.com/openbao/openbao/command (from $GOROOT) /nashome/d/dwd/gopath/src/github.com/openbao/openbao/command (from $GOPATH) That seems like such a fundamental issue that there must surely be a way around it but I didn't see how; probably you can tell me. > > There are a lot of ci checks done upstream with each PR. By unit tests, > > are you talking about testing individual source units that go into making > > openbao, or testing the openbao final binary "unit"? I assume it's the > > latter. I inquired about tests for that and was told that it's on their > > wish list but those kinds of release validation tests unfortunately do not > > yet exist. > > I was referring to the Go unit tests (*_test.go files) that can be run with > `go test` (or the `%gocheck` macro). Oh, there are those tests. However I learned that they take quite a long time and some of them use network. Is network allowed during the test phase? Since they're tests on the unchanged source code which have already been run upstream I don't see much value in running them again. > > The package does already have a sysusers configuration. > > It does, but there are still obsolete scripts to create the users. On Fedora > 42+, these scriptlets should not be included, as they will be created > automatically based on the sysusers file. Oh. Ok I surrounded that with a conditional to only be used on el8. > I'll let others chime in, but I suppose including a source archive from the > opensciencegrid repository for the config files isn't the end of the world, > if not super typical, but please make sure it's Source1, not Source0 which > should be reserved for the primary upstream archive, and add a comment above > the Source line explaining what it's used for. Done. > I would also consider > contributing these files upstream so other users and distro packagers can > use the same files and to avoid the need to maintain them in a separate > place and carry an extra source in the package. I will see if they're interested. They currently build rpms with goreleaser so I'm not sure they'll want these. > It seems one of the sources is licensed under CC0 > which is not allowed for new code in Fedora. If you identify which library > has this license, you could maybe do something like > https://src.fedoraproject.org/rpms/forgejo/blob/rawhide/f/forgejo.spec#_23, > but otherwise, you need to ask the upstream to change the License or get > Fedora Legal approval. It is the exact same library that forgejo is using so I copied that comment. The copr build is at https://copr.fedorainfracloud.org/coprs/dwd/openbao/build/9434111/. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2376217 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202376217%23c27 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
