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.
Those come directly from hunspell. $ hunspell Hunspell 1.4.0 https & https 1 0: HTTP config & config 3 0: con fig, con-fig, configure
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.
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
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.
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.
(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")
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.
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.
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.
(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.
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.
rpmlint-1.10-5.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f12a0c02a
rpmlint-1.10-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f0bd0e1259
rpmlint-1.10-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ff7ac149b3
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
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
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
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.
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.
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.