https://bugzilla.redhat.com/show_bug.cgi?id=811330
--- Comment #11 from Kalev Lember <kalevlember(a)gmail.com> ---
(In reply to comment #9)
> pcsc-cyberjack.src: W: spelling-error %description -l en_US
contactless ->
> con tactless, con-tactless, contact less
after a dictionary lookup, I decided to use 'non-contact' for the next
release
The dictionary that rpmlint uses obviously just doesn't know the technical
term. No need to fix every single rpmlint warning; we don't have to make all
packages rpmlint clean. This warning is rpmlint saying "Hey, I've noticed a
possible issue with your package, please check if this needs fixing."
> pcsc-cyberjack.x86_64: W: conffile-without-noreplace-flag
> /etc/udev/rules.d/92-cyberjack.rules
>
> * please add %config(noreplace)
I think this is wrong in two ways:
a) the file isn't really meant to be modified by the user, and as such
shouldn't be marked %config(noreplace);
b) it should be installed in /usr/lib/udev/rules.d/ instead so that it's clear
that it's a system file shipped by a package and not a config file that can be
modified.
So in this case rpmlint caught a valid issue but the fix isn't adding
%config(noreplace), but instead moving the file to another directory.
> pcsc-cyberjack.x86_64: W: devel-file-in-non-devel-package
> /usr/lib64/pcsc/drivers/libifd-cyberjack.bundle/Contents/Linux/libifd-
> cyberjack.so
>
> * it should be included in devel-package, or just remove it if there's no
> devel package
This one I am not sure about, I _think_ the .so needs to remain in that
location (compare pcsc-lite-ccid). But it will need someone more competent
in PC/SC than me to confirm.
Yes. pcscd dlopens the .so file directly and it's needed for proper
functioning. This .so file is a pcscd plugin. Another case of rpmlint warning
about a possible issue but where we know better.
> * the Free Software Foundation address in this file seems to be
outdated or
[...]
Also asked this from upstream.
Do I remember correctly that I am NOT to patch these two files until
upstream released an updated version or is it OK for me to patch the address
in this version and then revert my patch once upstream fixed it?
Yes, never patch any license files. This is for upstream to change, not
something a downstream packager should change. Notifying upstream and possibly
sending them a patch that fixes up the license headers is the correct thing to
do here.
See also
https://bugzilla.redhat.com/show_bug.cgi?id=700095
--
You are receiving this mail because:
You are on the CC list for the bug.