https://bugzilla.redhat.com/show_bug.cgi?id=2403985
--- Comment #5 from Oleg Girko <[email protected]> --- (In reply to Ben Beasley from comment #4) > (In reply to Oleg Girko from comment #3) > > Yes, definitely a false positive. "LGPL-3.0" is valid SPDX identifier: > > https://spdx.org/licenses/LGPL-3.0.html > > It is valid, but deprecated. Please use LGPL-3.0-only or LGPL-3.0-or-later > in Fedora instead. This project doesn’t use the usual GNU-prescribed license > notice (with the optional “or any later version” clause that would > distinguish between the two possibilities), but I do see that the license > headers in the source files all say “GNU Lesser General Public License v3+ > (LGPL)”, with the + indicating that LGPL-3.0-or-later is intended. Done. > There are also other licenses involved. It looks like you should have > something like: > > # The entire source is LGPL-3.0-or-later, except: > # - include/mcut/internal/cdt/ is MPL-2.0 Done. > # - include/mcut/internal/pool_allocator/ is MIT > # > # Additionally, include/mcut/internal/nfg/ is also LGPL-3.0-or-later, but > with a > # different copyright notice. There is neither pool_allocator nor ngf in include/mcut/internal in version 1.3.0. They are only in master branch. > License: LGPL-3.0-or-later AND MPL-2.0 AND MIT Done (without MIT that is only in master branch). > You should examine include/mcut/internal/{cdt,nfg,pool_allocator}/ to see if > they need to be handled as (partial) bundled dependencies under > https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling. include/mcut/internal/cdt has just a few headers that are used internally and not installed. Although they may be possibly originated in https://github.com/artem-ogre/CDT, Git history shows that they were significantly reworked. So, there's nothing here to unbundle. > If you want to repeat the long description text for the devel package, you > might like to put it in a macro to avoid duplication: Done. > You must not glob over the shared library ABI version / SONAME version like > this: > > %{_libdir}/libmcut.so.* > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > #_listing_shared_library_files Done. > The -devel package needs a fully-versioned, arched dependency on the base > package; see > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > #_requiring_base_package. > > Requires: mcut%{?_isa} = %{version}-%{release} Done. > You can drop %license LICENSE.txt from the -devel package since it depends > on the > base package, > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > LicensingGuidelines/#subpackage-licensing. Done. > If at all possible, you should build and run the tests. If this isn’t > possible, > please add a comment to the spec file explaining why. As tests require a library that is not packaged, I've just added a comment. > Patches should have comments explaining what they do, whether they’ve been > offered > upstream (with a link), or why they need to be downstream-only. > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > #_all_patches_should_have_an_upstream_bug_link_or_comment Done. > There’s no reason for the trailing .1 in “Release: 1%{?dist}.1”. Please ignore this. This is an artefact of building the package in OBS that requires two numbers in Release. There will be a single number in Fedora package. > These days, it’s recommended to use rpmautospec > (%autorelease/%autochangelog), > but this isn’t mandatory. > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/ > #_release_tag I feel more comfortable doing stuff the old-fashioned way. -- 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=2403985 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202403985%23c5 -- _______________________________________________ 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
