https://bugzilla.redhat.com/show_bug.cgi?id=1763285 --- Comment #4 from Lubomir Rintel <lkundrak@xxxxx> --- 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@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
