Apache OpenOffice (AOO) Bugzilla – Issue 125501
Spellcheck does not work, category B modules are missing (OS/2)
Last modified: 2016-12-31 15:37:36 UTC
This may be invalid, as I am reporting this for a release candidate, but here it is, anyway: Installed fresh 4.1.1 RC3, with new profile. Downloaded and installed latest English dictionary from official repository (compatible with OO4). Enabled option to check spelling while typing; no reported errors (even when intentionally misspelling). Pressing F7 or the toolbar button to begin a spellcheck finishes instantly with a message that no errors have been detected. Clicking OK closes the box (cannot stay to adjust settings). In options, I do not see where I might have missed enabling anything.
Dup of issue 121930
This is not a dup of issue 121930. Deleting the profile does not resolve this. This is apparently unique to the OS/2 RC.
I can confirm this. Deleting the user profile does not make spellchecking work.
Same issue here.
I first enabled spell modules, but then it turned out that it is part of so-called Category B items. So I have enabled Category B, this made spellchecker to be included; also solver module is now working, plus xslt filters and more scripting tools.
#i125501# build fixes for enabling Category B also in OS/2 port. Committed revision 1621121.
A binary update has been uploaded to dropbox download directory: Apache_OpenOffice_4.1.1_os2gcci_install-arc_en-US-RC3-update1.zip will spellchecker and solver dlls.
Thanks, Yuri. I haven't tested solver, xslt filters, or scripting, but can confirm that spelling is working (both spell-as-you-type and via the Spelling & grammar dialog). I'll mark this as fixed, as this was the sole purpose of this bug. Suggest that any other issues which arise now that this is functional raise separate tickets.
Forgot libs.mk changes... Committed revision 1623847.
"ydario" committed SVN revision 1623847 into trunk: #i125501# build fixes for enabling Category B also in OS/2 port.
"ydario" committed SVN revision 1621121 into trunk: #i125501# build fixes for enabling Category B also in OS/2 port.
"ydario" committed SVN revision 1642300 into trunk: #i125501# build fixes for enabling Category B also in OS/2 port.
Do these changed need to be ported to AOO410 branch for OS/2 4.1.2 building?
Kay, how to make sure this code and many others are landing in 4.1.2 branch too? I committed my patches only to trunk because it was not clear how/if to apply them to branches.
It is OK to make this a blocker since OS/2 is not officially distributed, but still it is good to be able to build on as many systems as possible. Code changes affect the OS/2 build only. @Yuri: feel free to merge your 3 patches to the AOO410 branch, see https://bz.apache.org/ooo/show_bug.cgi?id=126281#c11 for procedural details. Or any other committer can do it too.
Ok, I can merge my patches. What about patches for other tickets? can I merge them freely or I need some kind of authorization?
Everything that is relevant for 4.1.2 should be flagged with "Flags: 4.1.2 release blocker : ?". This triggers a mail to the dev list. Once, after possible discussion, the "?" is turned into a "+" (which means: the release blocker is approved) then anyone can merge the fix to AOO410. For 4.1.2 we tend to only allow important bugfixes or, to be more precise, bugfixes that do not carry a significant risk of side-effects.
All fixes I did in the trunk has been added on my personal branch for AOO 4.1.x, and the current OS/2 build is done using all existing trunk patches. Also patches are OS/2 only, they don't affect other code. So instead of merging to AOO branch, I can simply update my local branch as before. Just to avoid more discussions and slow down things.
(In reply to Andrea Pescetti from comment #17) > Everything that is relevant for 4.1.2 should be flagged with "Flags: 4.1.2 > release blocker : ?". This triggers a mail to the dev list. > > Once, after possible discussion, the "?" is turned into a "+" (which means: > the release blocker is approved) then anyone can merge the fix to AOO410. > > For 4.1.2 we tend to only allow important bugfixes or, to be more precise, > bugfixes that do not carry a significant risk of side-effects. Wouldn't it be less confusing in the long run to merge this OS/2 patch into the AOO410 trunk unless Yuri does all his builds from trunk normally. I was thinking if he (or anyone) releases an AOO 4.1.2 port it should be built from the correct branch and using the tarball that will be supplied.
Yuri, I didn't want to put any process here. Does trunk build under OS/2? Nice. Do you have a well-defined set of patches that could be applied to make the AOO410 branch build under OS/2? Perfect. Just re-apply those patches then, and we have a 4.1.2 source tarball that builds fine under OS/2. I don't see this as slowing down things. If you have commits on trunk that help the OS/2 build just merge them to AOO410. Even if they go beyond the three patches listed in this issue. But with the condition that all of them are, as you say, specific to OS/2 builds. In other words, should we move the action from here to the "parent issue" https://bz.apache.org/ooo/show_bug.cgi?id=118923 ?
Yes, the parent issue is the main tracker for os2 activity. Also it references some closed tickets whose changes are only in trunk. Should I add a '?' release blocker to all relevant tickets? (some older tickets are already merged to branch).
No need for special process, just feel free to go ahead and commit the relevant patches from the right issues. It will be easy (and lightweight) if you set "Target: 4.1.2" in those issues, but consider it a "nice to have". I've sent the following clarification to the dev list: --- As clarified with Yuri Dario (see issue): the commits in this specific issue are part of a bigger set of commits that are already in trunk and that Yuri can port to the AOO410 branch so that OpenOffice 4.1.2 will build on OS/2. All patches are OS/2 specific. The "blocker" flag is to be considered automatically extended to related issues and patches. Yuri Dario will personally pick the right ones and commit them to the AOO410 branch. ---