https://bugzilla.redhat.com/show_bug.cgi?id=2468312
--- Comment #4 from Cristian Le <[email protected]> --- > > - Whenever possible, please use `%autorelease`/`%autochangelog` [1], it > > helps other contributors, particularly with rebasing PRs > I don't think the upstream git repo is compatible with that. The upstream git repo does not play a role into this. The only fields that are affected are `Release` and `%changelog` which are downstream only. The git connection is with the dist-git, and even that one is not necessary. > But we surely don't need to include license files from every package that we > link to? Yes, that is not done in other packages either. Technically you need to add if any of the other symbols are re-compiled from the header file, e.g. C++ templates, but even that case is hard to track and is often overlooked. > I need access to the packager group to run scratch builds to see which of > those are already included in the standard build environment and can be > removed. Firstly you can use copr [1] to do the builds which are 90% the same as koji builds. `mock` would also do that. Secondly that is not what I was referring to. If it is a dependency defined from cmake requirement then yes explicitly define it. The one that made me raise my eyebrow was having both `make` and `ninja-build`. In the current list, `ninja-build` and `rpmdevtools` shold be dropped. > This package Obsoletes every version of that old package. You still MUST specify the specific version to obsolete even if that is the case. You can use a version higher to not have to sync with the release. > Consider an end-user who wants to read the doc files. Hardly any end-users > are familiar with either rtf or markdown. I beg a differ. Using the original markdown and rtf is common standard [2] and markdown is made to be human readable. In contrast ooffice conversion is not used in other packages [3]. The man page should be the recommended user-facing documentation. This is not a blocking issue for me though, so do as you wish. > If we use `%cmake` rather than `%cmake -DNO_GTEST=ON`, it does a git clone to > download googletest source code Please highlight this because there are standard workarounds. Please request upstream to use `FetchContent` instead of the manual build snippet in [4]. This is the modern CMake approach that is packager friendly and will work with `gtest-devel` out-of-the-box. You may ping me on the upstream issue (@LecrisUT) or point them to a reference like this one [5] [1]: https://copr.fedorainfracloud.org/coprs/ [2]: https://sourcegraph.com/search?q=context:global+repo:src.fedoraproject.org+README.md&patternType=keyword&sm=0 [3]: https://sourcegraph.com/search?q=context:global+repo:src.fedoraproject.org+ooffice&patternType=keyword&sm=0 [4]: https://github.com/pwsafe/pwsafe/blob/a2f591079e7d889a487c59d00e497549401ea88d/CMakeLists.txt#L225-L251 [5]: https://github.com/spglib/spglib/blob/12355c77fb7c505a55f52cae36341d73b781a065/test/CMakeLists.txt#L87-L102 -- 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=2468312 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202468312%23c4 -- _______________________________________________ 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://forge.fedoraproject.org/infra/tickets/issues/new
