Bug#608023: (no subject)
This should be fixed in Aspell 0.60.8 as aspell 0.60.8 increased the score of suggestions with a ' ', '-' so they no longer appear near the start of the list. The first suggestion is now 'transferred'
Bug#401120: fixed
This should be fixed in Aspell 0.60.8 as aspell 0.60.8 increased the score of suggestions with a ' ', '-' so they no longer appear near the start of the list.
Bug#935128: Packages potentially affected by unbounded buffer over-read in GNU Aspell 0.60.*
On Fri, 30 Aug 2019, Agustin Martin wrote: On Thu, Aug 29, 2019 at 12:20:28AM +0200, Agustin Martin wrote: On Mon, Aug 19, 2019 at 04:33:40PM -0400, Kevin Atkinson wrote: On Mon, 19 Aug 2019, Salvatore Bonaccorso wrote: See https://lists.gnu.org/archive/html/aspell-announce/2019-08/msg0.html Within Debian the "pumpa" will need an update. Others might be required as well. Kevin Atkinson might be up for help if needed. Also see http://aspell.net/buffer-overread-ucs.txt for a slightly improved version of the announcement that I edited for clarity. Hi all, This message is sent to all packages that depend in some way on libaspell15 (pdo addresses bcc'ed) A potentially unbounded buffer over-read has been found in in GNU Aspell 0.60.*. Package aspell 0.60.7-1 has been uploaded to Debian experimental, including upstream patch to deal with this problem. Unfortunately this fix may break applications that use null-terminated UCS-2 or UCS-4 strings with the C API. These applications will need to be fixed to make use of the new more secure API in order to continue to have a functional spell checker. This is the list of non aspell packages depending on libaspell15 which are possibly affected (maintainers bcc'ed). I did a preliminary analysis of most of these packages and here is what I found: eiskaltdcpp-qt -- no -- utf-8 enchant -- no -- utf-8 gnustep-gui-runtime -- no -- utf-8 inkscape -- no -- utf-8 kdelibs5-plugins libenchant1c2a -- no -- utf-8 libenchant2 -- unlikely -- [1] libenchant-voikko -- unlikely -- [2] librcc0 libtext-aspell-perl mcabber -- no -- user can set encoding, but always passes in length php7.3-pspell pumpa -- YES raspell sonnet-plugins tea -- no -- utf-8 weechat-plugins -- unlikely -- [3] xmlcopyeditor yagf "utf-8" means that it sets the encoding to utf-8 [1] I didn't check libenchant2 but it still likely sets the encoding to utf-8, but this should be verified. [2] libenchant-voikko is a plugin for enchant to use the voikko spell checker so I am not sure why it would directly use aspell [3] unsure what is going on with weechat, it will use enchant if available so the encoding is likely in utf-8, unsure what will happen if the ucs-2 encoding is set in an aspell config file KevinA (Aspell Maintainer)
Bug#935128: aspell: potentially unbounded buffer over-read in GNU Aspell 0.60.*
On Thu, 29 Aug 2019, Agustin Martin wrote: This message is sent to all packages that depend in some way on libaspell15 (pdo addresses bcc'ed) A potentially unbounded buffer over-read has been found in in GNU Aspell 0.60.*. Package aspell 0.60.7-1 has been uploaded to Debian experimental, including upstream patch to deal with this problem. It looks like you just applied the patches from Git. This will not work with a release as Aspell uses a lot of generated source files which are not checked into git. You need to run 'maintainer/autogen' to update them after applying the patch. Assuming the normal Debian build process rebuilds the automake/conf related bits then you can likely get away with just doing a: cd auto/ perl -I ./ mk-src.pl perl -I ./ mk-doc.pl touch auto cd .. There are some tests in test/. There not very expensive and will make sure that that Aspell is correctly patched with the new interface intended for working with wide-characters You should be able to run the tests by doing a make -C test The tests are completely independent of the normal build process. The build process reconfigures and rebuilds aspell into test/build and installs it locally into test/inst. It does configure with --enable-maintainer-mode so it might update some files in the source directory. If that is a problem you can easily patch the Makefile beforehand. I can also fix that upstream to make it easier to disable. Kevin (Aspell Maintainer)
Bug#935128: aspell: potentially unbounded buffer over-read in GNU Aspell 0.60.*
On Mon, 19 Aug 2019, Salvatore Bonaccorso wrote: See https://lists.gnu.org/archive/html/aspell-announce/2019-08/msg0.html Also see http://aspell.net/buffer-overread-ucs.txt for a slightly improved version of the announcement that I edited for clarity.
Bug#795159: hunspell-en-us dictionary is outdated
Hi, On Tue, 18 Aug 2015, Rene Engelhard wrote: retitle 795159 please update to uptodate SCOWL versions thanks Hi, On Tue, Aug 18, 2015 at 04:21:34PM +0700, Ake K. wrote: AFAIK, The real SF's upstream hunspell en-US dictionary is [1]http://sourceforge.net/projects/wordlist/files/Hunspell/ CCing Kevin Atkinson, Upstream Maintainer on en_US Hunspell dictionary for confirm. If so, we should just remove the hunspell-en-* (source) packages then and package the non-large(!) variants out of scowl itself by using the same script used to create what you can download on that sf download page. I confirm that is the source the the real SF's upstream hunspell en-US dictionary. Cc'ing the scowl maintainer. If you agree I can send you a patch doing this and/or do it myself as (prospective) co-maintainer... I am a little confused who this is directed at. The script to make the dictionaries from SCOWL is included in SCOWL. It should work from a release tarball however it is not well tested that way. It may be safer to use the git source on github (https://github.com/kevina/wordlist) as that is how it is used in my release scripts. Kevin
Bug#795159: hunspell-en-us dictionary is outdated
On Tue, 18 Aug 2015, Rene Engelhard wrote: On Tue, Aug 18, 2015 at 01:36:57PM -0400, Kevin Atkinson wrote: I confirm that is the source the the real SF's upstream hunspell en-US dictionary. Cc'ing the scowl maintainer. If you agree I can send you a patch doing this and/or do it myself as (prospective) co-maintainer... I am a little confused who this is directed at. Sorry, yeah, it was adressed to Don. The script to make the dictionaries from SCOWL is included in SCOWL. It should work from a release tarball however it is not well tested that way. Doesn't, afaics. (sid)rene@frodo:~/scowl-7.1/speller$ ./make-hunspell-dict prep creating en_US.dic cat: en-common.wl: No such file or directory cat: en_US-wo_accents-only.wl: No such file or directory or how is it supposed to be used? You are using an old version of SCOWL, but with the latest you should be able to do make hunspell. It may be safer to use the git source on github (https://github.com/kevina/wordlist) as that is how it is used in my release scripts. Yeah, but I think we should stay with releases (means: release tarballs) if ever possible. The safest think is to use the pre-made zips uploaded to http://sourceforge.net/projects/wordlist/files/speller/ and not have to worry about created the dictionaries from the SCOWL source.
Bug#778495: Sorry For the Duplicate Report
Sorry for the duplicate report. I wasn't sure how to file it. Please remove either this one or #778496. Kevin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778495: New Upstream Version of aspell-en Available
Source: aspell-en Hi, This is a quick note that an new upstream version is now available at ftp://ftp.gnu.org/gnu/aspell/dict/en/aspell6-en-2015.02.15-0.tar.bz2 I will likely be updating more frequently now. So is there is some way to watch ftp://ftp.gnu.org/gnu/aspell/dict/en, that might be a good idea. Thanks, Kevin Atkinson Upstream Maintainer of aspell-en -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778496: New Upstream Version of aspell-en Available
Package: aspell-en Version: 7.1-0-1 Hi, This is a quick note that an new upstream version is now available at ftp://ftp.gnu.org/gnu/aspell/dict/en/aspell6-en-2015.02.15-0.tar.bz2 I will likely be updating more frequently now. So is there is some way to watch ftp://ftp.gnu.org/gnu/aspell/dict/en, that might be a good idea. Thanks, Kevin Atkinson Upstream Maintainer of aspell-en -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632023: New Upstream Version of Aspell English Dictionaries Available
Source: aspell-en Version: 6.0-0-6 A new upstream version of the Aspell English Dictionary has been available for several mouths now, see http://wordlist.sourceforge.net/ and http://ftp.gnu.org/gnu/aspell/dict/en/. The new version contain numerous correction and the enhancements since the version 6.0 which was released over 6 years ago. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#310590: Notes On Building Aspell Dictionaries
On Fri, 1 Jul 2005, Agustin Martin wrote: On Thu, Jun 30, 2005 at 06:08:28PM -0600, Kevin Atkinson wrote: This seems something to be decided in a per dict basis and delegated on dict maintainers. Yes that is why I suggest you use the settings in the official Aspell dictionary package. If the Debian dictionary maintainer thinks otherwise I would appreciate an email to that effect. We usually try to avoid duplicating sources, so many of the aspell dicts are not built from the official Aspell dictionary package, but from the original (usually ispell) wordlist + aff table, with some elements taken from the official Aspell dictionary package. I don't particularly agree with that position. I will write more when I find the time. Nevertheless, dict maintainers should at least be in tune with the settings of the official dictionary package. Also the versioning of official Aspell dictionary packages makes difficult to know which is the involved upstream version The new Aspell dictionaries now use a version number to match the upstream version. Eventually all dictionary will be converted to use the new format. I plan to try taking Debian aspell-es maintenance in the near future; since I maintain the espa~nol source package, that provides ispanish and myspell-es, all the required sources are already there (and more up to date, using espa~nol 1.8 instead of 1.7). Since this has no phonetic code, is a clear candidate for affix compression. That is one of the dictionaries I have been meaning to update. -- http://kevin.atkinson.dhs.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310590: Notes On Building Aspell Dictionaries
A few things to take into consideration. 1) To Minimize the Space Used The Word List Should be Compressed with prezip -s. (The -s is to resort the word list using the C local which is needed for maximum compressed with prezip). And than further compressed with bzip2. You can decompress it by piping it through bzcat | precat. To give you an idea on sizes using various methods here are the file sizes for en-common.wl (.cwl is the word list compressed with prezip) 1224 en-common.wl 424 en-common.cwl 136 en-common.cwl.bz2 164 en-common.cwl.gz 432 en-common.wl.bz2 332 en-common.wl.gz yes bzip2 is WORSE than gzip on a sorted word list. Also prezip and friends consists of an ANSI C program and some shell scripts which can easily be separated out into a separate package so that you can also use them with Ispell if so desired. 2) To avoid spitting out a bunch of warnings during compile you should clean it by piping it though aspell clean strict. This will remove all problem words and affix flags that Aspell will complain about when compiling. The compiled dictionary should be the same with either the dirty or the clean word list. You can also use aspell clean but that but that handles some errors in a different way and the resulting compiled dictionary may be different. 3) Aspell by defaults performs a number of checks when creating a word list, some if these can be expensive. You can disable the expensive one with --dont-validate-affixes. If you clean the word list first this should be 100% safe. It should also be safe to use on a dirty word list as the invalid affix flags don't cause a problem in the compiled word list. You may also consider using --validate-words but those checks are not very expensive. -- Kevin Atkinson Aspell Author http://kevin.atkinson.dhs.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310590: Notes On Building Aspell Dictionaries
On Thu, 30 Jun 2005, Agustin Martin wrote: On Thu, Jun 30, 2005 at 05:39:29AM -0600, Kevin Atkinson wrote: A few things to take into consideration. 1) To Minimize the Space Used The Word List Should be Compressed with prezip -s. (The -s is to resort the word list using the C local which is needed for maximum compressed with prezip). And than further compressed with bzip2. You can decompress it by piping it through bzcat | precat. To give you an idea on sizes using various methods here are the file sizes for en-common.wl (.cwl is the word list compressed with prezip) 1224 en-common.wl 424 en-common.cwl 136 en-common.cwl.bz2 164 en-common.cwl.gz 432 en-common.wl.bz2 332 en-common.wl.gz yes bzip2 is WORSE than gzip on a sorted word list. Also prezip and friends consists of an ANSI C program and some shell scripts which can easily be separated out into a separate package so that you can also use them with Ispell if so desired. Thanks for the hints, Kevin I assume this applies only to non affix compressed wordlists. No it also helps with affix compressed word lists. I think we should also encourage affix compression when possible, hash sizes are much better. If the language in question does not have does not have any sort of soundslike data, than affix compression is a clear win; however, if the language uses phonetic soundslike data (such as German, French, and most importunately English) than the choice to enable affix compression in the compiled hash table is much more difficult. Aspell will support both affix compression and phonetic soundslike lookup but the results may not be as good. Thus I, in general, don't recommend it. You should use the settings in the official dictionary package. Regarding bzip2, it implies adding another dependency. While most systems already have it installed I personally prefer using gzip, which must always be present, even if that implies a larger size. Well bzip2 is very common now and in fact my dictionary packages use bzip2 and no one has complained yet. This sounds like a policy decision that should possibly be discussed with other Debian developers (or whoever the appropriate people are on policy decisions such as that). One point against bzip2 is that it is slower, however this may not make much of a difference as most of the time will be spend in compiling the word list: $ time gunzip -c en-common.cwl.gz | precat | aspell --lang=en create master ./en-common.rws real0m3.160s user0m3.020s sys 0m0.130s $ time bunzip2 -c en-common.cwl.bz2 | precat | aspell --lang=en create master ./en-common.rws real0m3.438s user0m3.280s sys 0m0.130s I won't say anything else on this point, as it is not something I fell very strongly about. All the last tests I did were using plain gzip and affix compressed wordlists. Only the very first tests were done with gzipped raw (no prezip) wordlists. Since the system seems viable, I will add support for prezip/precat if wordlist name is of the form .cwl.gz. -- http://kevin.atkinson.dhs.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310590: Notes On Building Aspell Dictionaries
On Thu, 30 Jun 2005, Kevin Atkinson wrote: 3) Aspell by defaults performs a number of checks when creating a word list, some if these can be expensive. You can disable the expensive one with --dont-validate-affixes. If you clean the word list first this should be 100% safe. It should also be safe to use on a dirty word list as the invalid affix flags don't cause a problem in the compiled word list. You may also consider using --validate-words but those checks are not very expensive. That should be --dont-validate-words. -- http://kevin.atkinson.dhs.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310590: Notes On Building Aspell Dictionaries
On Fri, 1 Jul 2005, Agustin Martin wrote: I think we should also encourage affix compression when possible, hash sizes are much better. If the language in question does not have does not have any sort of soundslike data, than affix compression is a clear win; however, if the language uses phonetic soundslike data (such as German, French, and most importunately English) than the choice to enable affix compression in the compiled hash table is much more difficult. Aspell will support both affix compression and phonetic soundslike lookup but the results may not be as good. Thus I, in general, don't recommend it. You should use the settings in the official dictionary package. This seems something to be decided in a per dict basis and delegated on dict maintainers. Yes that is why I suggest you use the settings in the official Aspell dictionary package. If the Debian dictionary maintainer thinks otherwise I would appreciate an email to that effect. You may also consider using --validate-words but those checks are not very expensive. That should be --dont-validate-words. Thanks, I only added --dont-validate-affixes, I tested only gl-minimos and ca, and catalan dict has some useless flags. Piping through aspell clean strict gave me a lot of errors on the 'point in the middle char' that is used in catalan as part of words, and I think that I had errors even on flag slashes in the affix compressed ispell wordlist. You need to be sure to specify the correct language ie aspell clean strict -l lang the set of warnings should be the same as when compiling the word list, if not you did something wrong. If the language data file is not installed in the expected location you might need to add --local-data-dir=path. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295748: [aspell-devel] Unhandled Error bug
On Fri, 18 Feb 2005, Brian Nelson wrote: Hi Kevin, Can you please take a look at http://bugs.debian.org/295748 and see if you can figure out what's going on there? I've also received a report that the same error happens even without a personal dictionary present. This will be fixed in Aspell 0.60.3. You can download a snapshot at ftp://alpha.gnu.org/gnu/aspell/aspell-0.60.3-20050121.tar.gz. This snapshot should be at least as stable as Aspell 0.60.2. I have been meaning to release Aspell 0.60.3 for a while. There are a few additional bugs I want to look into before I do. -- http://kevin.atkinson.dhs.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294294: ghc6 conflicts with mzscheme
Package: ghc6 Version: 6.2.2-2 Severity: important ghc6 conflicts with mzscheme. I belive this is due to the fact that ghc6 depends on libreadline4-dev while mzscheme depends on libreadline5-dev. I think the solution would be to recompile ghc6 with libreadline5. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.4.21 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages ghc6 depends on: ii gcc-3.3 1:3.3.5-5The GNU C compiler ii haskell-utils 1.6 Utilities used by the Debian Haske ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libgmp3 4.1.4-5 Multiprecision arithmetic library ii libgmp3-dev 4.1.4-5 Multiprecision arithmetic library ii libncurses5 5.4-4Shared libraries for terminal hand ii libreadline44.3-11 GNU readline and history libraries ii libreadline4-dev4.3-11 GNU readline and history libraries ii perl [perl5]5.8.4-5 Larry Wall's Practical Extraction -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
