https://bugzilla.redhat.com/show_bug.cgi?id=1763285
--- Comment #4 from Lubomir Rintel <lkundrak(a)v3.sk> ---
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_.22...
> 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