https://bugzilla.redhat.com/show_bug.cgi?id=2376217 --- Comment #27 from Dave Dykstra <dwd@xxxxxxx> --- (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 -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
