Bug 509387 - alpine: use hunspell (instead of aspell)
Summary: alpine: use hunspell (instead of aspell)
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: alpine
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Joshua Daniel Franklin
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-02 14:49 UTC by Caolan McNamara
Modified: 2009-07-06 16:51 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-06 16:51:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
patch to make configure do the right thing when explicitly given a spellchecking program to use (2.95 KB, patch)
2009-07-02 14:49 UTC, Caolan McNamara
no flags Details | Diff
sample src.rpm (4.98 MB, application/x-rpm)
2009-07-06 08:04 UTC, Caolan McNamara
no flags Details

Description Caolan McNamara 2009-07-02 14:49:13 UTC
Created attachment 350291 [details]
patch to make configure do the right thing when explicitly given a spellchecking program to use

Description of problem:
As described at http://fedoraproject.org/wiki/Releases/FeatureDictionary we've been trying to unify dictionaries in Fedora for some time. alpine is configured to use and require aspell, it'd be better to use hunspell

Version-Release number of selected component (if applicable):
alpine-2.00-5.fc11.i586

a) --with-spellcheck-prog=aspell
isn't right afaics, the configure options should actually be
--with-simple-spellcheck=FOO \
--with-interactive-spellcheck=FOO
luckily enough as it turns out because if it has been =aspell etc the configure script wouldn't have tacked on the correct options to aspell
b) need to patch the configure to accept "aspell"/"hunspell" and then tag on the correct options to it.

I attach that patch here, FWIW I'm a bit baffled as to how to submit a patch upstream to http://www.washington.edu/alpine if you know how to contact them properly

Comment 1 Rex Dieter 2009-07-02 15:05:26 UTC
Upstream as it was, is pretty much dead.  There's a re-alpine fork happening...

Otherwise, this patch looks promising, thanks!

Comment 2 Joshua Daniel Franklin 2009-07-02 15:39:45 UTC
Sounds good to me. No releases yet for re-alpine so maybe we can go ahead and carry this patch in Fedora.

Comment 3 Rex Dieter 2009-07-05 03:41:24 UTC
Meh, my limited auto-foo mojo is failing me.  No amount of autoreconf, or automake/autoconf seems to work here.

Maybe it'll be in our best interest to switch to using re-alpine sooner rather than later. (ie, a git checkout of re-alpine does work).

Comment 4 Caolan McNamara 2009-07-06 08:04:05 UTC
Created attachment 350581 [details]
sample src.rpm

how about this, builds for me (tm)

Comment 5 Rex Dieter 2009-07-06 14:51:08 UTC
Wierd, same problem here (I should have posted details before)...

+ autoreconf -f -i
cvs [init aborted]: Cannot initialize repository under existing CVSROOT: `/home/rdieter1/cvs.fedoraproject.org'
cvs [checkout aborted]: /home/rdieter1/cvs.fedoraproject.org/alpine/devel/alpine-2.00/tmpcvs1749/CVSROOT: No such file or directory
find: `archive': No such file or directory
find: `archive': No such file or directory
find: `archive': No such file or directory
autopoint: *** infrastructure files for version 0.16.1 not found; this is autopoint from GNU gettext-tools 0.17
autopoint: *** Stop.
autoreconf: autopoint failed with exit status: 1


Is my cvs checkout borked to to blame here somehow?

Comment 6 Rex Dieter 2009-07-06 15:00:45 UTC
Seems to build ok in mock, so it must by my own setup to blame somehow.

Comment 7 Caolan McNamara 2009-07-06 15:10:35 UTC
Probably due to the autoreconf process calling autopoint which "does something" and uses \"cvs\" for some reason of its own which I guess is failing if you on a local build. Layering hack upon hack with 

export AUTOPOINT=/bin/true
autoreconf -f -i

might hackaround

Comment 8 Rex Dieter 2009-07-06 15:40:38 UTC
cool, thanks.

OK, testing out, seems hunspell needs to specify a dictionary via -d , meh, just default to en_US or grok $LANG somehow (or whack hunspell to autochoose a reasonable default)?

Comment 9 Caolan McNamara 2009-07-06 15:53:36 UTC
hunspell should already be choosing a reasonable default based on (in order).
LANGUAGE, LC_ALL, LC_MESSAGES, LANG, falling back finally to en_US. There *may* have been some glitches in this in F-11 (though generally should have worked), with all well in rawhide AFAIK

Comment 10 Rex Dieter 2009-07-06 16:51:30 UTC
OK, considering the aspell status-quo wasn't much better, I'm ok with that.

I'll commit the patch for alpine/devel branch regardless.


I can confirm though, on F-11 at least, hunspell appears broken:

rpm -q hunspell
hunspell-1.2.8-5.fc11.x86_64

echo $LANG
en_US.UTF-8

hunspell <file>
=> ERROR:  Can't open affix or dictionary files for dictionary named "".

I'll open a bug soonish.


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