[Bug 1763285] Review Request: libnma - NetworkManager GUI library
https://bugzilla.redhat.com/show_bug.cgi?id=1763285 Mattia Verga changed: What|Removed |Added Status|POST|CLOSED Resolution|--- |CURRENTRELEASE Last Closed||2021-07-18 14:26:21 --- Comment #10 from Mattia Verga --- Package is in repos, closing review -- 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 ___ package-review mailing list -- package-review@lists.fedoraproject.org To unsubscribe send an email to package-review-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1763285] Review Request: libnma - NetworkManager GUI library
https://bugzilla.redhat.com/show_bug.cgi?id=1763285 Thomas Haller changed: What|Removed |Added CC||thal...@redhat.com --- Comment #9 from Thomas Haller --- OK, some progress. To recap: - at this point in Fedora we have network-manager-applet-1.8.24, this contains subpackage libnma-1.8.24 Now, we got new upstream releases with libnma is split out of network-manager-applet: - libnma-1.8.26 (ignore, superceded) - libnma-1.8.28 - network-manager-applet-1.16.0 Upstream references: - https://gitlab.gnome.org/GNOME/libnma - https://gitlab.gnome.org/GNOME/network-manager-applet Resources: - patch for dist-git for updating to libnma-1.8.28 (on top of current Fedora master) [1] https://gitlab.gnome.org/thaller/network-manager-applet/-/commits/dist-git-master-libnma - patch for dist-git for updating to network-manager-applet-1.16.0 (on top of current Fedora master) [2] https://gitlab.gnome.org/thaller/network-manager-applet/-/commits/dist-git-master-network-manager-applet - koji scratch build of libnma-1.8.28 above: https://koji.fedoraproject.org/koji/taskinfo?taskID=42274874 Note that building network-manager-applet-1.16.0 requires libnma-1.8.28, so I didn't do a scratch build of that. However, I built RPMs with `fedpkg local`, see here: https://gitlab.gnome.org/thaller/network-manager-applet/-/commits/nm-applet-prebuilt-rpms I'd like to push [1] and [2] to dist-git and do a koji build. Does this sound good to everyone? I have no commit rights to libnma, so I cannot do it myself. -- 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 ___ package-review mailing list -- package-review@lists.fedoraproject.org To unsubscribe send an email to package-review-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[Bug 1763285] Review Request: libnma - NetworkManager GUI library
https://bugzilla.redhat.com/show_bug.cgi?id=1763285 --- Comment #8 from Lubomir Rintel --- No, this needs to be fixed upstream first and that's gonna take some time. libnma-1.8.26-3.fc32 ought to be untagged from f32 for the time being, but it seems that it has been done already. -- 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 ___ package-review mailing list -- package-review@lists.fedoraproject.org To unsubscribe send an email to package-review-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[Bug 1763285] Review Request: libnma - NetworkManager GUI library
https://bugzilla.redhat.com/show_bug.cgi?id=1763285 Kevin Fenzi changed: What|Removed |Added CC||ke...@scrye.com --- Comment #7 from Kevin Fenzi --- So, this is currently breaking rawhide composes (the kde live media): 21:51:52,350 WRN packaging: Problem 1: conflicting requests - package initial-setup-gui-0.3.78-1.fc32.x86_64 requires anaconda-gui >= 32.13-1, but none of the providers can be installed - package anaconda-gui-32.14-1.fc32.x86_64 requires nm-connection-editor, but none of the providers can be installed - nothing provides libnma(x86-64) = 1.8.24-1.fc32 needed by nm-connection-editor-1.8.24-1.fc32.x86_64 Problem 2: conflicting requests - package anaconda-live-32.14-1.fc32.x86_64 requires anaconda-gui = 32.14-1.fc32, but none of the providers can be installed - package anaconda-gui-32.14-1.fc32.x86_64 requires nm-connection-editor, but none of the providers can be installed - nothing provides libnma(x86-64) = 1.8.24-1.fc32 needed by nm-connection-editor-1.8.24-1.fc32.x86_64 Problem 3: conflicting requests - package anaconda-32.14-1.fc32.x86_64 requires anaconda-gui = 32.14-1.fc32, but none of the providers can be installed - package anaconda-gui-32.14-1.fc32.x86_64 requires nm-connection-editor, but none of the providers can be installed - nothing provides libnma(x86-64) = 1.8.24-1.fc32 needed by nm-connection-editor-1.8.24-1.fc32.x86_64 Problem 4: conflicting requests - package kdump-anaconda-addon-005-6.20190723gitc109552.fc32.noarch requires anaconda >= 21.33, but none of the providers can be installed - package anaconda-32.14-1.fc32.x86_64 requires anaconda-gui = 32.14-1.fc32, but none of the providers can be installed - package anaconda-gui-32.14-1.fc32.x86_64 requires nm-connection-editor, but none of the providers can be installed - nothing provides libnma(x86-64) = 1.8.24-1.fc32 needed by nm-connection-editor-1.8.24-1.fc32.x86_64 21:54:52,975 DBG dnf: os-release: User-Agent constructed: libdnf (Fedora 32; generic; Linux.x86_64) I guess this needs adjustment in the network-manager-applet package? can we do that soon? -- 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 ___ package-review mailing list -- package-review@lists.fedoraproject.org To unsubscribe send an email to package-review-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[Bug 1763285] Review Request: libnma - NetworkManager GUI library
https://bugzilla.redhat.com/show_bug.cgi?id=1763285 --- Comment #6 from Gwyn Ciesla --- (fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/libnma -- 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 ___ package-review mailing list -- package-review@lists.fedoraproject.org To unsubscribe send an email to package-review-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[Bug 1763285] Review Request: libnma - NetworkManager GUI library
https://bugzilla.redhat.com/show_bug.cgi?id=1763285
Matthew Krupcale changed:
What|Removed |Added
Status|ASSIGNED|POST
Flags|fedora-review? |fedora-review+
--- Comment #5 from Matthew Krupcale ---
Package approved.
Package Review
==
Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
= MUST items =
C/C++:
[-]: Provides: bundled(gnulib) in place as required.
Note: Sources not installed
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: If your application is a C or C++ application you must list a
BuildRequires against gcc, gcc-c++ or clang.
[x]: Header files in -devel subpackage, if present.
[x]: ldconfig not called in %post and %postun for Fedora 28 and later.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.
[x]: Development (unversioned) .so files in -devel subpackage, if present.
Generic:
[x]: Package successfully compiles and builds into binary rpms on at least
one supported primary architecture.
Note: Using prebuilt packages
[x]: Package is licensed with an open-source compatible license and meets
other legal requirements as defined in the legal section of Packaging
Guidelines.
[x]: License field in the package spec file matches the actual license.
Note: There is no build directory. Running licensecheck on vanilla
upstream sources. No licenses found. Please check the source files for
licenses manually.
[x]: License file installed when any subpackage combination is installed.
[x]: If the package is under multiple licenses, the licensing breakdown
must be documented in the spec.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[x]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: The spec file handles locales properly.
[x]: Package consistently uses macros (instead of hard-coded directory
names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[x]: If the package is a rename of another package, proper Obsoletes and
Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
(~1MB) or number of files.
Note: Documentation size is 10240 bytes in 2 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the
license(s) in its own file, then that file, containing the text of the
license(s) for the package is included in %license.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package must not depend on deprecated() packages.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
%{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local
= SHOULD items =
Generic:
[x]: Reviewer should test that the package builds in mock.
[x]: If the source package does not include license text(s) as a separate
file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]:
[Bug 1763285] Review Request: libnma - NetworkManager GUI library
https://bugzilla.redhat.com/show_bug.cgi?id=1763285 Lubomir Rintel changed: What|Removed |Added Flags|needinfo?(lkund...@v3.sk) | -- 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 ___ package-review mailing list -- package-review@lists.fedoraproject.org To unsubscribe send an email to package-review-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[Bug 1763285] Review Request: libnma - NetworkManager GUI library
https://bugzilla.redhat.com/show_bug.cgi?id=1763285
--- Comment #4 from Lubomir Rintel ---
Thank you.
(In reply to Matthew Krupcale from comment #3)
> A couple minor things I spotted after now building -gtk4 packages in rawhide
> and a bit more discussion on some points from the last review, and then this
> should be ready.
>
> > No, libnma doesn't obsolete libnma-gtk
>
> Okay, I suppose the network-manager-applet spec file libnm-gtk-devel package
> description was incorrect then.
>
> > I'll do that once the network-manager-applet package is updated and
> > libnm-gtk is actually dropped.
>
> It looks like libnm-gtk{,devel} was last built in F28, though. So is this
> not already essentially dropped?
Ah, yes. The point still stands though -- fedora-obsolete-packages should
obsolete it.
> > No, it's the presence of %files section or lack thereof that decides
> > whether a binary package is built. That is so by design.
>
> I only meant that the subpackages should not be defined in addition to the
> %files section being excluded. This was mainly just so it was clear for the
> reader only looking at the %package's what was built when, consistent with
> the %files. It's not a requirement as far as I can tell but only a
> suggestion.
I got that right. I'm not going to do that, it just seem to add noise.
> > Yes. This needs to get fixed upstream first:
> > https://gitlab.gnome.org/GNOME/libnma/merge_requests/5
>
> I believe you should go ahead and update the License: field and comment in
> the spec file (either around the License: field or in %files) about the
> shared/ license without having the COPYING.LGPL file included yet. In the
> next release you can include the file (assuming it's accepted upstream), but
> the license should still be correctly labeled.
Okay, done.
Note that this shouldn't have been necessary because the effective license was
correct:
https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F
> > Yeah, it could be done, but it seems rather unnecessary to me at this point.
>
> I think it is good practice for three reasons:
> 1. Being noarch, the package can be built and installed anywhere
> 2. Reduces the repository size since the docs subpackages are not
> duplicated for each arch
> 3. Potentially reduces the download and install size for the user if docs
> are optional
>
> I don't believe this is a requirement, but I do think it's recommended,
> considering the size (>1 MB) of the documentation here.
No. This is a package that most people won't install, and is certainly not
going to be present in systems where 1 M matters at all.
> Issues:
> ===
> - mobile-broadband-provider-info only Required by -gtk4 but appears to be
> used by libnma as well
Fixed.
> - Spelling error in -gtk4-devel Summary: "exerimental" -> "experimental"
Fixed.
SPEC: http://v3.sk/~lkundrak/SPECS/libnma.spec
SRPM: http://v3.sk/~lkundrak/SRPMS/libnma-1.8.26-3.fc32.src.rpm
--
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
___
package-review mailing list -- package-review@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
[Bug 1763285] Review Request: libnma - NetworkManager GUI library
https://bugzilla.redhat.com/show_bug.cgi?id=1763285
Matthew Krupcale changed:
What|Removed |Added
Flags||needinfo?(lkund...@v3.sk)
--- Comment #3 from Matthew Krupcale ---
A couple minor things I spotted after now building -gtk4 packages in rawhide
and a bit more discussion on some points from the last review, and then this
should be ready.
> No, libnma doesn't obsolete libnma-gtk
Okay, I suppose the network-manager-applet spec file libnm-gtk-devel package
description was incorrect then.
> I'll do that once the network-manager-applet package is updated and libnm-gtk
> is actually dropped.
It looks like libnm-gtk{,devel} was last built in F28, though. So is this not
already essentially dropped?
> No, it's the presence of %files section or lack thereof that decides whether
> a binary package is built. That is so by design.
I only meant that the subpackages should not be defined in addition to the
%files section being excluded. This was mainly just so it was clear for the
reader only looking at the %package's what was built when, consistent with the
%files. It's not a requirement as far as I can tell but only a suggestion.
> Yes. This needs to get fixed upstream first:
> https://gitlab.gnome.org/GNOME/libnma/merge_requests/5
I believe you should go ahead and update the License: field and comment in the
spec file (either around the License: field or in %files) about the shared/
license without having the COPYING.LGPL file included yet. In the next release
you can include the file (assuming it's accepted upstream), but the license
should still be correctly labeled.
> Yeah, it could be done, but it seems rather unnecessary to me at this point.
I think it is good practice for three reasons:
1. Being noarch, the package can be built and installed anywhere
2. Reduces the repository size since the docs subpackages are not duplicated
for each arch
3. Potentially reduces the download and install size for the user if docs are
optional
I don't believe this is a requirement, but I do think it's recommended,
considering the size (>1 MB) of the documentation here.
Package Review
==
Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
Issues:
===
- mobile-broadband-provider-info only Required by -gtk4 but appears to be used
by libnma as well
- Spelling error in -gtk4-devel Summary: "exerimental" -> "experimental"
- License should be "GPLv2+ and LGPLv2+" due to contents in shared/
Should install COPYING.LGPLv2.1.
This should be documented in the spec file as well.
See:
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_multiple_licensing_scenarios
- -gtk4 and -gtk4-devel subpackages should only be defined when
%if %{with libnma_gtk4}
- Consider moving %{_datadir}/gtk-doc files to noarch -devel-doc subpackage
See:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_documentation
= MUST items =
C/C++:
[-]: Provides: bundled(gnulib) in place as required.
Note: Sources not installed
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: If your application is a C or C++ application you must list a
BuildRequires against gcc, gcc-c++ or clang.
[x]: Header files in -devel subpackage, if present.
[x]: ldconfig not called in %post and %postun for Fedora 28 and later.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.
[x]: Development (unversioned) .so files in -devel subpackage, if present.
Generic:
[x]: Package successfully compiles and builds into binary rpms on at least
one supported primary architecture.
Note: Using prebuilt packages
[x]: Package is licensed with an open-source compatible license and meets
other legal requirements as defined in the legal section of Packaging
Guidelines.
[!]: License field in the package spec file matches the actual license.
Note: There is no build directory. Running licensecheck on vanilla
upstream sources. No licenses found. Please check the source files for
licenses manually.
[x]: License file installed when any subpackage combination is installed.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[x]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: The spec file handles locales properly.
[x]: Package consistently uses macros (instead of hard-coded directory
names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package
[Bug 1763285] Review Request: libnma - NetworkManager GUI library
https://bugzilla.redhat.com/show_bug.cgi?id=1763285
Lubomir Rintel changed:
What|Removed |Added
Flags|needinfo?(lkund...@v3.sk) |
--- Comment #2 from Lubomir Rintel ---
(In reply to Matthew Krupcale from comment #1)
> For the most part, this is close to ready, except for a few {Build,}Requires
> and Obsoletes issues and license packaging details.
>
> Since this is splitting off from network-manager-applet, I looked at that
> spec file, and it seems to indicate that libnma{,-devel} should obsolete
> libnm-gtk{,-devel}.
No, libnma doesn't obsolete libnma-gtk. It is gone without a replacement -- the
Obsoletes should go to fedora-obsolete-packages. I'll do that once the
network-manager-applet package is updated and libnm-gtk is actually dropped.
> Issues:
> ===
> - If your application is a C or C++ application you must list a
> BuildRequires against gcc, gcc-c++ or clang.
> Note: No gcc, gcc-c++ or clang found in BuildRequires
> See: https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/
Fixed.
> - %bcond_without should be used for defining with by default
> You may have this backwards for libnma_gtk4
> See: https://rpm.org/user_doc/conditional_builds.html
Good catch, thanks. Fixed.
> - -devel and -gtk4-devel should require arch-dependent library packages:
> Requires: %{name}%{?_isa} = %{version}-%{release}
> and
> Requires: %{name}-gtk4%{?_isa} = %{version}-%{release}
> respectively
> See:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/
> #_requiring_base_package
Yes. Fixed.
> - -gtk4 and -gtk4-devel subpackages should only be defined when
> %if %{with libnma_gtk4}
No, it's the presence of %files section or lack thereof that decides whether a
binary package is built. That is so by design.
> - Should Obsoletes: libnm-gtk{,-devel}
See above.
> - %ldconfig_scriptlets is unnecessary on F28+
> See: https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
Dropped it.
> - License should be "GPLv2+ and LGPLv2+" due to contents in shared/
> Should install COPYING.LGPLv2.1.
> This should be documented in the spec file as well.
> See:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/
> LicensingGuidelines/#_multiple_licensing_scenarios
Yes. This needs to get fixed upstream first:
https://gitlab.gnome.org/GNOME/libnma/merge_requests/5
> - License not installed with -gtk4
Fixed.
> - Consider moving %{_datadir}/gtk-doc files to noarch -devel-doc subpackage
> See:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_documentation
Yeah, it could be done, but it seems rather unnecessary to me at this point.
Updated package:
SPEC: http://v3.sk/~lkundrak/SPECS/libnma.spec
SRPM: http://v3.sk/~lkundrak/SRPMS/libnma-1.8.26-2.fc31.src.rpm
--
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
___
package-review mailing list -- package-review@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
[Bug 1763285] Review Request: libnma - NetworkManager GUI library
https://bugzilla.redhat.com/show_bug.cgi?id=1763285
Matthew Krupcale changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||mkrupcale@matthewkrupcale.c
||om
Assignee|nob...@fedoraproject.org|mkrupcale@matthewkrupcale.c
||om
Flags||fedora-review?
||needinfo?(lkund...@v3.sk)
--- Comment #1 from Matthew Krupcale ---
For the most part, this is close to ready, except for a few {Build,}Requires
and Obsoletes issues and license packaging details.
Since this is splitting off from network-manager-applet, I looked at that spec
file, and it seems to indicate that libnma{,-devel} should obsolete
libnm-gtk{,-devel}. However, this currently seems to obsolete a much older
NetworkManager-gtk-devel (also missing obsoletes on the main library package).
Package Review
==
Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
Issues:
===
- If your application is a C or C++ application you must list a
BuildRequires against gcc, gcc-c++ or clang.
Note: No gcc, gcc-c++ or clang found in BuildRequires
See: https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/
- %bcond_without should be used for defining with by default
You may have this backwards for libnma_gtk4
See: https://rpm.org/user_doc/conditional_builds.html
- -devel and -gtk4-devel should require arch-dependent library packages:
Requires: %{name}%{?_isa} = %{version}-%{release}
and
Requires: %{name}-gtk4%{?_isa} = %{version}-%{release}
respectively
See:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_requiring_base_package
- -gtk4 and -gtk4-devel subpackages should only be defined when
%if %{with libnma_gtk4}
- Should Obsoletes: libnm-gtk{,-devel}
- %ldconfig_scriptlets is unnecessary on F28+
See: https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
- License should be "GPLv2+ and LGPLv2+" due to contents in shared/
Should install COPYING.LGPLv2.1.
This should be documented in the spec file as well.
See:
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_multiple_licensing_scenarios
- License not installed with -gtk4
- Consider moving %{_datadir}/gtk-doc files to noarch -devel-doc subpackage
See:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_documentation
= MUST items =
C/C++:
[-]: Provides: bundled(gnulib) in place as required.
Note: Sources not installed
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: Header files in -devel subpackage, if present.
[x]: ldconfig not called in %post and %postun for Fedora 28 and later.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.
[x]: Development (unversioned) .so files in -devel subpackage, if present.
Generic:
[x]: Package successfully compiles and builds into binary rpms on at least
one supported primary architecture.
Note: Using prebuilt packages
[x]: Package is licensed with an open-source compatible license and meets
other legal requirements as defined in the legal section of Packaging
Guidelines.
[!]: License field in the package spec file matches the actual license.
Note: There is no build directory. Running licensecheck on vanilla
upstream sources. No licenses found. Please check the source files for
licenses manually.
[!]: License file installed when any subpackage combination is installed.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[x]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: The spec file handles locales properly.
[x]: Package consistently uses macros (instead of hard-coded directory
names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[!]: If the package is a rename of another package, proper Obsoletes and
Provides are present.
[!]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[!]: Large documentation must go in a -doc subpackage. Large could be size
(~1MB) or
