Bug 1424684 - rpmlint reports invalid spelling errors
Summary: rpmlint reports invalid spelling errors
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rpmlint
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-18 03:53 UTC by Andrew Toskin
Modified: 2017-11-11 03:08 UTC (History)
8 users (show)

Fixed In Version: rpmlint-1.10-5.fc25 rpmlint-1.10-5.fc26 rpmlint-1.10-5.fc27
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-06 23:33:25 UTC


Attachments (Terms of Use)

Description Andrew Toskin 2017-02-18 03:53:09 UTC
I'm working on some packages that contain a URL in the %description block. rpmlint complains about a supposed spelling error in the web protocol:

  ... W: spelling-error %description -l en_US https -> HTTP

I get similar warnings for the word "config", which I believe is a common enough abbreviation that it should be added to the spelling dictionary.

I'm using fedora-review 0.6.1 f03e4e7 2016-05-02, and rpmlint 1.9 on Fedora 25 Workstation x86_64.

Comment 1 Ville Skyttä 2017-02-18 19:13:34 UTC
Those come directly from hunspell.

$ hunspell 
Hunspell 1.4.0
https
& https 1 0: HTTP

config
& config 3 0: con fig, con-fig, configure

Comment 2 Zbigniew Jędrzejewski-Szmek 2017-02-18 20:57:20 UTC
I doubt that the fix can be done in hunspell. "config" is not a real word, but it's CS jargon. IMHO rpmlint has to do filtering on it's own, for example for common informatic jargon and the name of the package and such.

Comment 3 Caolan McNamara 2017-02-18 21:14:47 UTC
Yeah, its a general purpose English language spell checking dictionary, you'd get similar stuff spell checking medical forms or anything else which has its own technical subset, so I wouldn't like to add "weird" words to general purpose English dictionaries.

But hunspell can be called like this...

hunspell -d en_US,rpmtechnical

and there could be an additional rpmtechnical.dic like this...

2
config
URL

in which special terminology allowed in spec files can be added

Comment 4 Ville Skyttä 2017-02-19 07:20:08 UTC
rpmlint already does some filtering, e.g. the mentioned package names and such.

One valid approach towards most jargon is just avoiding it. Don't say "config", say "configuration".

Anyway, IMO clearly if hunspell-en accepts "HTTP", it should also accept "HTTPS". (It doesn't accept either in lowercase, which is fine as far as I'm concerned.)

Anyway my personal position (also as part of upstream rpmlint) is that I'm almost certainly not going to be doing anything about this in rpmlint, at least in the foreseeable future.

Comment 5 Jason Tibbitts 2017-02-19 19:11:56 UTC
rpmlint doesn't even check all upper case words, or capitalized words that don't start a sentence.

Anyway, I would expect any regular spell check to flag those things.  
I just add them to my personal enchant dictionary (because rpmlint actually uses enchant, which uses myspell, which uses hunspell) and the rpmlint stops complaining.

It would be pretty nice if there was an easy way to pass rpmlint a list of words to ignore.  The spell checking functions already take a list which is constructed in TagsCheck:check() from all components of all the files in the package and all of the package dependencies (provides/requires/conflicts/obsoletes).

It would be pretty trivial to extend that set from an rpmlint config setting.  I would provide a patch but I have to learn how to actually add config settings to rpmlint.

Comment 6 Ville Skyttä 2017-02-20 10:08:33 UTC
(In reply to Jason Tibbitts from comment #5)
> It would be pretty nice if there was an easy way to pass rpmlint a list of
> words to ignore.

The generic way to mute any unwanted messages from rpmlint in its config works for this, I don't think there's need for a more specific one.  For example to "accept" https and config, something like this should work:

addFilter(r"spelling-error.* \b(https|config)\b")

Comment 7 Zbigniew Jędrzejewski-Szmek 2017-02-21 00:30:35 UTC
That's not useful if we require every packager who uses rpmlint to define their own spelling fixes. If you are checking some package and see a false positive, you are not going to add configuration to silence that one warning. It's not like you're going to be ever checking the same package again. This would only be useful to do in rpmlint itself.

Comment 8 Jason Tibbitts 2017-02-21 00:48:20 UTC
Neither rpmlint nor Fedora's supplied configuration files would ever be able to account for every single false positive spelling issue seen in a package.  rpmlint's spelling check can't possibly be seen as anything other than a quick check for the package maintainer.  If we start adding filters for non-dictionary words then I'm not sure where it ends, and I think I'd rather advocate for turning off the spelling check by default than try to keep track of a big word list.

But in any case, it's not my decision.  I will say, though, that this once again makes me desperately wish we could embed some kind of limited directives for rpmlint within specfiles.

Comment 9 Zbigniew Jędrzejewski-Szmek 2017-02-21 02:52:34 UTC
I run rpmlint on the packages installed on my system. The most common spelling "errors" that are diagnosed (at least 5 occurences):

      5 assistive
      5 bitmapped
      5 checkpolicy
      5 codecs
      5 dialogs
      5 executables
      5 GObject
      5 initramfs
      5 iSCSI
      5 libcom
      5 libgcrypt
      5 libsoup
      5 libudev
      5 libxcb
      5 lowlevel
      5 middleware
      5 namespace
      5 pinentry
      5 py
      6 argparse
      6 boolean
      6 datetime
      6 io
      6 libmagic
      6 libvirt
      6 malloc
      6 passphrase
      6 pragma
      7 adaptors
      7 bootloader
      7 cairo
      7 config
      7 devel
      7 distributable
      7 embeddable
      7 hypervisor
      7 libaudit
      7 preprocessor
      7 realtime
      7 spi
      8 freedesktop
      8 gbm
      8 glapi
      8 libpng
      8 posix
      8 udev
      9 encodings
      9 GLib
      9 libc
      9 libs
      9 libXss
      9 tcp
     10 bitstream
     10 customizable
     10 Kerberos
     10 pixbuf
     10 pluggable
     10 scalable
     10 trie
     10 truetype
     11 codec
     12 extensibility
     12 http
     12 utils
     13 GStreamer
     14 glyphs
     15 crypto
     15 libvirtd
     15 toolkits
     15 virtualization
     16 backends
     16 lossless
     17 util
     18 Runtime
     19 Wayland
     20 addon
     20 filesystems
     20 userspace
     21 backend
     25 filesystem
     26 linux
     26 multi
     28 cryptographic
     31 metadata
    207 runtime

I really think that those should not be flagged as errors. They are jargon, but commonly used and spelled correctly for our purposed. We really could generate a custom dictionary based on current spec files. That would cover maybe 95% of new false positives.

(This is based on installed packages that I happen to have. For some reason that I did not debug rpmlint does not flag spelling errors on spec files. A full set of packages should be used to generate a real list of course.)

There *are* a few true positives further up the list. If the false ones were filtered out, more people might actually look at this, and fix the true positives.

Comment 10 Ville Skyttä 2017-02-21 07:28:28 UTC
(In reply to Jason Tibbitts from comment #8)
> I will say, though, that this once
> again makes me desperately wish we could embed some kind of limited
> directives for rpmlint within specfiles.

It's not in specfiles, but a similar mechanism exists in fedpkg (well rpkg actually). You can place a .rpmlint file with rpmlint configs in it in a package's clone dir and run "fedpkg lint" there. The .rpmlint file can be checked into git and will also be to my knowledge be used by autoqa's rpmlint checks from there.

Comment 11 Jason Tibbitts 2017-02-21 18:11:03 UTC
Right, but that's actually terrible.

It absolutely should not be a hidden file.  I cannot comprehend why anyone would think that to be a good idea, given the following.

Here's how rpmlint config files are loaded:

    with open(expconf) as fobj:
        exec(compile(fobj.read(), expconf, 'exec'))

So, uh, let's checkin a .rpmlint file (hidden, of course, because that was a good idea) that does, well, whatever you want.

A "safe" config file, or some non-code annotations within the spec itself, would go a long way towards making this actually useful.  But until then, you simply can't trust an rpmlint config you get from somewhere.  Which means you can't do the really useful things like have your editor automatically run rpmlint with a config file stored in with the package.  (Unless you're really careful.)

Anyway, that's all sadly off-topic for this ticket.

Comment 12 Fedora Update System 2017-10-29 17:03:35 UTC
rpmlint-1.10-5.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f12a0c02a

Comment 13 Fedora Update System 2017-10-29 17:03:52 UTC
rpmlint-1.10-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f0bd0e1259

Comment 14 Fedora Update System 2017-10-29 17:04:06 UTC
rpmlint-1.10-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ff7ac149b3

Comment 15 Fedora Update System 2017-10-30 14:46:41 UTC
rpmlint-1.10-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ff7ac149b3

Comment 16 Fedora Update System 2017-10-30 16:42:26 UTC
rpmlint-1.10-5.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f12a0c02a

Comment 17 Fedora Update System 2017-10-30 17:06:28 UTC
rpmlint-1.10-5.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f0bd0e1259

Comment 18 Fedora Update System 2017-11-06 23:33:25 UTC
rpmlint-1.10-5.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 19 Fedora Update System 2017-11-06 23:33:57 UTC
rpmlint-1.10-5.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Comment 20 Fedora Update System 2017-11-11 03:08:53 UTC
rpmlint-1.10-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.