Bug 143368
| Summary: | abiword - various CRITICAL messages | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
| Component: | abiword | Assignee: | Caolan McNamara <caolanm> |
| Status: | CLOSED RAWHIDE | QA Contact: | Mike McLean <mikem> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-01-14 08:49:00 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
strace and gdb bit looks like a kernel problem (see bug #143350). With that resolved from traces follows that AbiWord looks at the content of /usr/share/AbiSuite-2.2/dictionary/ispell_dictionary_list.xml and from that it seems that indeed it expects dictionaries in a format used by ispell. Small wonder that it cannot find anything as only aspell dictionaries, in a diffrent format, are provided on a system; with an apparent exception of a single /usr/share/AbiSuite-2.2/dictionary/american.hash and which is not found anyway. Wrong encoding? It appears that an adjustment to use aspell dictionaries is necessary. It is also possibly unrelated to other problems. Hmm, abiword really wants enchant to be installed thesedays... Might package enchant and configure enchant to use aspell and then problem should go away. Should work in 2.2.2-2 coming soon dictionary warning should be solved in available rawhide abiword-2.2.2-2 Dictionary warnings are indeed gone but all these CP !<CluePacket> ..... Dashboard: Sending cluepacket... Dashboard: connect: Connection refused with sizeable chunks of text in them, are all over the place. abiword-2.2.2-3. If the above is indeed a garbage (but what this "Connection refused" is supposed to mean?) then why not turn that off? I'll handle the cluepacket problems as RH#145085# as its unrelated to the spell checking error messages. |
Description of problem: When trying to open various documents (RTF or M$-word produced files) with abiword-2.2.2-1 I am getting alerts like that: Could not load the dictionary for the English (Canada)[en-CA] language. Could not load the dictionary for the English (US)[en-US] language. Sometimes even both for the same document. aspell-en-0.51-11.x86_64 is installed on the test system. What abiword would like to open it is somewhat hard to find out as strace abiword <some_document> just sits at the initial 'execve("/usr/bin/abiword", .... ) = 0' and 'gdb abiword' never gets to a '(gdb)' prompt. This with "SELINUX=disabled" in /etc/sysconfig/selinux before will anybody ask. OTOH on a console abiword is all the time producing messages like these: I've been notified!! Text is |Introduction| CP !<CluePacket> <Frontend>Abiword</Frontend> <Context>Abiword</Context> <Focused>true</Focused> <Clue Type="textblock" Relevance="10">Introduction</Clue> </CluePacket> ! Dashboard: Sending cluepacket... Dashboard: connect: Connection refused Illegal format hash table 1 (AbiWord-2.2:5205): Gtk-CRITICAL **: file gtkfilesystemunix.c: line 793 (gtk_file_system_unix_get_parent): assertion `g_path_is_absolute (filename)' failed (AbiWord-2.2:5205): libgsf:msole-CRITICAL **: file gsf-infile-msole.c: line 113 (ole_get_block): assertion `block < ole->info->max_block' failed On occasions in these <Clue ...> ... </Clue> brackets one gets quite sizeable chunks of a text. Once past all these hurdles a text in an editor window seems to look as usual. This is marked 'x86_64' for now as I simply do not know if this happens on x86 too or not. Version-Release number of selected component (if applicable): abiword-2.2.2-1 How reproducible: Every time