https://bugzilla.redhat.com/show_bug.cgi?id=811330 --- Comment #11 from Kalev Lember <kalevlember@xxxxxxxxx> --- (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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review