Bug#385403: aspell-ru: hash file is not created

--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by edison.ccupm.upm.es id k8OKYF4J011939

On Sat, Sep 23, 2006 at 09:12:28PM +0300, Martin-=C9ric Racine wrote:
> Hello Brian,
>=20
> It seems that a recent release of the Russian wordlist (source:
> rus-ispell) contains words that aspell interprets as illegal, which mak=
es
> the hash generation break, leaving users with an empty hash file (Bug
> #385403) and making this an RC bug. Both words definitely exist in the
> Russian language, so I am unsure how to solve this issue. Any ideas?

The error message

=3D=3D=3D=3Dpostinst log=3D=3D=3D
????????????? ????? aspell-ru (0.99g3-1) ...
aspell-autobuildhash: processing: ru [ru]
??????: /usr/lib/aspell//ru_affix.dat:1246: The condition "???" does not
guarantee that "????" can always be stripped.
aspell-autobuildhash: processing: ru [ru]
??????: /usr/lib/aspell//ru_affix.dat:1246: The condition "???" does not
guarantee that "????" can always be stripped.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

suggests that rule described in line 1246 of ru_affix.dat is wrong, and
cannot always be executed for the given string. Indeed, looking at that
rule, I see something that, expressed in terms of 7bit chars, looks like

SFX L estn as stn

that means, if you find 'stn' strip 'estn' (Buggy!!!) and replace it by
'as'. But if you have something like 'astn' rule is matched, but you cann=
ot
strip 'estn', hence the error.

I have blindly modified that line to something possible and I then find a
different set of errors and warnings,

---------------------
Warning: The word "???" is invalid. The total length is larger than 240
characters. Skipping word.
...
Error: The word "?????????" is invalid. The total word length, with
soundslike data, is larger than 240 characters.
---------------------

which disappear if I use the .wl file instead of the .cwl for building th=
e
hash (I also removed the offending number from the first line of the
wordlist). I tested this in a aspell personal sarge backport, so I cannot
confirm if this means only that my backport is buggy or if is a general
problem. I hope to try that tomorrow with a current aspell.

Regarding the original problem, the right ru_affix.dat fix is definitely
something for rus-ispell upstream, or at least for somebody fluent with
russian.

I am attaching a patch with the changes I used here to test that the rule
was failing. Do not consider it a real patch, I do not speak russian, jus=
t a
dummy test.

Hope this helps

--=20
Agustin

--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename="ru_affix.dat.dummypatch"
Content-Transfer-Encoding: base64
X-MIME-Autoconverted: from 8bit to base64 by edison.ccupm.upm.es id k8OKYF4J011939

LS0tIHJ1X2FmZml4LmRhdC5vcmlnCTIwMDYtMDktMjQgMjI6MDU6MzguMDAwMDAwMDAwICsw
MjAwDQorKysgcnVfYWZmaXguZGF0CTIwMDYtMDktMjQgMjI6MDU6NTUuMDAwMDAwMDAwICsw
MjAwDQpAQCAtMTI0NCw3ICsxMjQ0LDcgQEANCiBTRlggTCAgINPRICAgzMHT2CAgICAgICAg
IFtewcnR2F3T0Q0KIFNGWCBMICAgxd7Y09Ego8vT0SAgICAgICAgIMXe2NPRDQogU0ZYIEwg
ICDF3tggIKPLICAgICAgICAgICDF3tgNCi1TRlggTCAgIMXa1Mkgo9ogICAgICAgICAgINrU
yQ0KK1NGWCBMICAgxdrUySCj2iAgICAgICAgICAgxdrUyQ0KIFNGWCBMICAgxdPU2CDMzyAg
ICAgICAgICAg3sXT1NgNCiBTRlggTCAgIMXT1NggzMkgICAgICAgICAgIN7F09TYDQogU0ZY
IEwgICDF09TYIMzBICAgICAgICAgICDexdPU2A0K
--+QahgC5+KEYLbs62--