https://bugzilla.redhat.com/show_bug.cgi?id=2376217 --- Comment #26 from Maxwell G <maxwell@xxxxxxx> --- Hi, > The main problem with %gobuild is not that it isn't supported in EPEL8, it is that it doesn't support adding tags as far as I can tell, and openbao needs to add a tag. Do you know of a way to do it? There's also no way to add gcflags, although I only use those for optional debugging so they're not strictly required. 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 defintion)` such as -gcflags. > 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). > 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. > I added an MIT-2.0 LICENSE file to the openbao-rpm repo, the same as the upstream. I understand that the spec file will need to be primarily sourced for Fedora & EPEL from the pkgs.fedoraproject.org git, but I'd like to be able to continue to use this as the source for the extra files if it is allowed. That way there's a single primary source for those extra files instead of a copy per fNN and epelN branch, and I can have github actions to test things before building on koji. 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. 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 thought the latest iteration did have a License tag in a proper SPDX expression including the licenses of all the vendored packages, but I see now it is supposed to have `AND` as uppercase instead of lowercase. I made that change too. Thanks, I see it now. 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. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component 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%23c26 -- _______________________________________________ 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
