Arches masking zemberek USE flag can skip zemberek-server. Thanks, Serkan
sparc stable. I did package.use.mask zemberek for enchant because it requires java. I note however that currently zemberek seems to be masked globally anyway.
(In reply to comment #1) > sparc stable. I did package.use.mask zemberek for enchant because it requires > java. I note however that currently zemberek seems to be masked globally > anyway. Correct: ./base/package.use.mask:app-text/enchant zemberek Stable for HPPA.
amd64/x86 stable
ppc stable
This totally breaks spellchecking on my system. You need to have an announcement that the default dictionary no longer is referenced, I think. This is from an email I'm sending to -user: Claws-mail version 3.7.0 Locale: en_US.UTF-8 (charset: UTF-8) Spell checker could not be started. Couldn't initialize en dictionary: (null) Couldn't initialize en speller. eix app-dicts/*en [I] app-dicts/aspell-en Available versions: 0.51.0 0.51.1 6.0.0 Installed versions: 6.0.0(08:11:33 AM 04/15/2008) Homepage: http://aspell.net Description: English (US, British, Canadian) language dictionary for aspell ??? Did someone change an ebuild, or profile or something, without an announcement somewhere? eix app-dicts/*en [I] app-dicts/aspell-en Available versions: 0.51.0 0.51.1 6.0.0 Installed versions: 6.0.0(08:11:33 AM 04/15/2008) Homepage: http://aspell.net Description: English (US, British, Canadian) language dictionary for aspell equery depends app-dicts/aspell-en [ Searching for packages depending on app-dicts/aspell-en... ] app-text/aspell-0.60.5 (!linguas_vi & !linguas_uk & !linguas_sv & !linguas_sr & !linguas_sl & !linguas_sk & !linguas_ru & !linguas_ro & !linguas_pt & !linguas_pl & !linguas_no & !linguas_nl & !linguas_it & !linguas_is & !linguas_hr & !linguas_he & !linguas_gl & !linguas_ga & !linguas_fr & !linguas_fo & !linguas_fi & !linguas_et & !linguas_es & !linguas_eo & !linguas_en & !linguas_el & !linguas_de & !linguas_da & !linguas_cy & !linguas_cs & !linguas_ca & !linguas_br & !linguas_bg & !linguas_be & !linguas_af? app-dicts/aspell-en) (linguas_en? app-dicts/aspell-en) app-text/enchant-1.4.2 (aspell? virtual/aspell-dict) [I] app-text/enchant Available versions: 1.2.5 1.3.0 1.4.2 {aspell hunspell zemberek} Installed versions: 1.4.2(07:07:10 PM 01/25/2009)(hunspell -aspell -zemberek) Homepage: http://www.abisource.com/enchant/ Description: Spellchecker wrapping library So, what is a user supposed to do in this case? It appears that the profile, or something, is defaulted to something other than what it did before (aspell --> hunspell maybe?), but this change maybe wasn't propogated to the user who needs to do something, I suppose. At least, not this user... where did the change originate? This was updated yesterday, so I assume this really is the culprit. alculating dependencies... done! [ebuild R ] app-text/enchant-1.4.2 USE="hunspell -aspell -zemberek" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] n Quitting. lappy ~ # grep enchant /var/lib/portage/world Geez! I was about to pollute world. Hello, WTF???? app-office/abiword-2.6.4 (spell? >=app-text/enchant-1.2) app-text/gtkspell-2.0.14 (>=app-text/enchant-1.1.6) mail-client/claws-mail-3.7.0 (spell? >=app-text/enchant-1.0.0) So, is abiword spellcheck broken too? Yep. I just rebuild 'enchant', no messages that my system is broken. [ebuild R ] app-office/abiword-2.6.4 USE="gnome spell -debug -xml" 0 kB So, "spell" enabled. Why not working? Anyway, I don't know the best route to proceed. It seems like 'aspell' is just orphaned on my system, since it isn't used. I didn't make that choice to orphan it, or break the spellchecking. Checking again, nowhere is 'aspell' or 'hunspell' specified in my use flags. Thoughts, anyone? Google search causes many hits, no doubt the solution is either to remove 'aspell' and emerge hunspell en dicts, or add 'aspell' use, but since this is a dependency enabled by default somewhere, why doesn't it try to, or prompt to, install a proper dictionary if the default changed by devs? diff enchant-1.4.2.ebuild /usr/portage/app-text/enchant/enchant-1.4.2.ebuild 1c1 < # Copyright 1999-2008 Gentoo Foundation --- > # Copyright 1999-2009 Gentoo Foundation 3c3 < # $Header: /var/cvsroot/gentoo-x86/app-text/enchant/enchant-1.4.2.ebuild,v 1.2 2008/07/20 06:04:56 serkan Exp $ --- > # $Header: /var/cvsroot/gentoo-x86/app-text/enchant/enchant-1.4.2.ebuild,v 1.5 2009/01/23 22:37:39 maekke Exp $ 14c14 < KEYWORDS="~alpha ~amd64 ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86 ~x86-fbsd" --- > KEYWORDS="~alpha amd64 hppa ~ia64 ~ppc ~ppc64 sparc x86 ~x86-fbsd" ^^^ Hmm. I think I found the problem, the cause, the culprit.
michael from your report I see that you have aspell dictionaries installed but you built enchant without aspell USE flag. What happens it you build enchant with aspell USE flag?
(In reply to comment #6) > michael from your report I see that you have aspell dictionaries installed but > you built enchant without aspell USE flag. What happens it you build enchant > with aspell USE flag? > Someone needs to amend the ebuild with either a sanity check (does spell checking still work?) or an announcement that a change was made that doesn't consider the PROFILES' default USE flags and you'll have to make some (likely uninformed) decision about which dicts/* you should use.
(In reply to comment #7) > (In reply to comment #6) > > michael from your report I see that you have aspell dictionaries installed but > > you built enchant without aspell USE flag. What happens it you build enchant > > with aspell USE flag? > > > > Someone needs to amend the ebuild with either a sanity check (does spell > checking still work?) or an announcement that a change was made that doesn't > consider the PROFILES' default USE flags and you'll have to make some (likely > uninformed) decision about which dicts/* you should use. > I discovered by experimentation that for claws-mail, it needs enchant-1.4.2 with USE=aspell. Apparently this comes about because now enchang prefers hunspell, but previously it would prefer aspell. I suppose either enchant should default USE=aspell or claws-mail should be spell-checker neutral beyond using enchant.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > michael from your report I see that you have aspell dictionaries installed but > > > you built enchant without aspell USE flag. What happens it you build enchant > > > with aspell USE flag? > > > > > > > Someone needs to amend the ebuild with either a sanity check (does spell > > checking still work?) or an announcement that a change was made that doesn't > > consider the PROFILES' default USE flags and you'll have to make some (likely > > uninformed) decision about which dicts/* you should use. > > > > I discovered by experimentation that for claws-mail, it needs enchant-1.4.2 > with USE=aspell. Apparently this comes about because now enchang prefers > hunspell, but previously it would prefer aspell. I suppose either enchant > should default USE=aspell or claws-mail should be spell-checker neutral beyond > using enchant. > It broke abiword too, just FYI. The problem isn't claws-mail specific. And yes, it is happening because previously there was a preference (+aspell), the ebuild changed the preference (+hunspell), so it (the ebuild) is broken. It has nothing to do with claws-mail -- at least, in the current version the dep is on "enchant" for "spell", which is correct, and has been fine for months. It is the enchant ebuild which needs fixing to accommodate this change. Or, so I believe. '-)
(In reply to comment #9) > It broke abiword too, just FYI. The problem isn't claws-mail specific. > > And yes, it is happening because previously there was a preference (+aspell), > the ebuild changed the preference (+hunspell), so it (the ebuild) is broken. It > has nothing to do with claws-mail -- at least, in the current version the dep > is on "enchant" for "spell", which is correct, and has been fine for months. It > is the enchant ebuild which needs fixing to accommodate this change. Or, so I > believe. '-) > you just need to install the proper dictionaries according to the use flag you have chosen for enchant. The ebuild does nothing wrong. Now if you're not satisfied with current defaults I'll ask you to open another bug so as to not bother arches with this. @ferris, if claws-mail uses enchant in a non spellchecking-engine agnostic way, there is some serious problem in claws-mail code that needs reporting.
(In reply to comment #8) > I discovered by experimentation that for claws-mail, it needs enchant-1.4.2 > with USE=aspell. Apparently this comes about because now enchang prefers > hunspell, but previously it would prefer aspell. I suppose either enchant > should default USE=aspell or claws-mail should be spell-checker neutral beyond > using enchant. > That's not the case. See bug #250115
I've added warning into ebuild, so users will be aware about this situation. If we get more reports I'll have to issue news item about this change... hunspell now is default spell checker library. BTW, we already tell our users that if they emerged hunspell they'll have to emerge myspell-<lang> dictionaries. Just take a look at output at the end of hunspell emerge...
(In reply to comment #12) > I've added warning into ebuild, so users will be aware about this situation. If > we get more reports I'll have to issue news item about this change... hunspell > now is default spell checker library. BTW, we already tell our users that if > they emerged hunspell they'll have to emerge myspell-<lang> dictionaries. Just > take a look at output at the end of hunspell emerge... > I'm sure this is fine. Just to recap, since there seems to be some confusion: I never chose a dictionary *before*, so the *function* is (undeniably) broken... from what it was. Someone made a choice to change the function, it deserves an announcement, IMO... (or, the change is a mistake, so needs to be fixed to get back the original function). IOW, 'spell' use flag, picked up by default in the 'desktop' profile, *used* to emerge a working spellchecker, now it doesn't. I hope that is clear. I can't see where the decision to degrade the function was debated, discussed and approved... like everything. Hunspell probably was emerged in a terminal as part of a deep 'world' update, so it is very likely I wasn't able to view the message. I just re-emerged hunspell and saw it... Doesn't seem very much like a *warning*, though. Remember, the *function* of the ebuild called by 'spell' has changed, so this would be *important* to communicate. I think 'aspell' pulled a dicts/* based on the locale, avoiding user intervention entirely -- and getting it right to boot. Yes, that's true... maybe this code could be adapted for 'hunspell' too. Finally, the 'aspell' ebuild does elog, *ewarn* and *ebeep* -- so you *can't* miss it -- for 5 seconds anyway, it is displayed. (This is probably the better solution...) Anyway, that's enough about it. My feeling is, it worked great before, it doesn't work so great now. I understand that the user intervention is trivial, but I think the function is degraded to what it was before. Ideally the dicts/* would be pulled in as a dependency based on the locale and 'spell' use flag -- just like it used to. What's *wrong* with that, I wonder? Would anyone emerge a spellchecker and *not* want it to work? ;-)
ppc64 done but i had to mask the zemerek use for ppc64 as it doesnt build.
I have to revert this stabilization since regression for stable systems was found: bug 256564. As soon as we resolve it, we'll proceed stabilization another time. Sorry guys.
(In reply to comment #15) > I have to revert this stabilization since regression for stable systems was > found: bug 256564. As soon as we resolve it, we'll proceed stabilization > another time. Sorry guys. > The bug was fixed. When can we file a stabilization for that?
(In reply to comment #16) > The bug was fixed. When can we file a stabilization for that? Bug fixed, but month has not passed to make gnome-spell-1.0.8-r2 go stable. So we need to wait until 10 Mar 2009. But probably if gnome team will be ready to move gnome 2.24 stable around that time it's good idea to do all of this in one go. In gnome 2.24 at least some applications dropped usage of gnome-spell and use enchant directly - which is a good thing :)
All arches done, closing.
