OpenOffice.org

OpenOffice.org package guidelines

1. Minimize differences from upstream, ideally we should have no fedora-specific patches at all
2. All patches must either...
3. contain the upstream issuezilla id in the patch name
4. or if the patch or related patchset has been accepted into upstream then name the patch as the workspace name
5. or if the changes is not upstreamable then contain the fedora bug id in the patch name instead
6. be aggressively pursued upstream to either get then accepted and merged, or clearly refused
7. When OpenOffice.org releases it's first master workspace along the release branch, i.e. OOX680mY, then it becomes acceptable to import into rawhide at this stage, but not during the development SRC680_mY stage.
8. Retain the upstream rpm version as the base fedora version, e.g. OOE680m6 was the cvs tag for the upstream 2.1.0-6 rpms, so the fedora rpms must be 2.1.0-6.X where X is the fedora rpm version
9. the fedora OpenOffice.org rpms should be split similarly to the upstream rpms, e.g. -core, -base, -writer, the various langpacks, etc
10. The fedora OpenOffice.org tarball must only be imported by the package maintainer and it should be checked out with ooocvs
11. Messing with ARCH_FLAGS is a sure way to create a non-functional OpenOffice.org

OpenOffice.org extension rpm guidelines

See Packaging/OpenOffice.orgExtensions

OpenOffice.org langpack rpm guidelines

1. Must build the langpack only if the locale is supported by glibc (locale -a)
2. Must build the langpack only if there is a font available in fedora to render that language
3. The langpack should Require: a font to render that language
4. The langpack should Require: a spell-check dictionary for the language if available, e.g. hunspell-en, hunspell-de
5. The langpack should Require: a hyphenation dictionary for the language if available, e.g. hyphen-en, hyphen-de
6. The langpack should Require: a thesaurus for the language if available, e.g. mythes-en, mythes-de
7. The new langpack must be added by inserting an appropriate entry into langpackdetails in the .spec

OpenOffice.org bug handling guidelines

1. Bugs should reference the upstream bug id through the external link option which lists OpenOffice.org's issuezilla as an option
2. Bugs should be responded to in a timely fashion to reassure that it has been read
3. Bugs should not be allowed to rot, if it can't be fixed, either move it upstream for consideration, or close and explain why it's not going to be fixed
4. Stacktraces from the crash reporter should be mapped back through debuginfo to the original source lines with ooomapstack . Attach the mapped stack to the bug as text/plain
5. Bugs must be moved to the correct component, e.g.
6. Print Dialog issues, see if it affects evince as well, -> gtk2
7. File Dialog issues, see if it affects firefox or eclipse as well -> gtk2
8. Text Rendering issues, clarify if it is an icu issue, -> icu
9. Database issues, clarify if it is a hsqldb issue, -> hsqldb
10. el bizarro bug, clarify if it affects another large c++ program, e.g. firefox -> verify that compilation toolchain is ok
11. Verify that all installed files are non-corrupt, e.g. check for suspicious output in

/etc/cron.daily/prelink
rpm -Va

OpenOffice.org potted workarounds

1. Use GNOME
2. Try enabling tools->options->openoffice.org->general->Use OpenOffice.org Dialog
3. Disable accessibility
4. Revert to fedora supplied java rpms
5. Revert to fedora supplied libstdc++
6. Revert to fedora supplied video drivers
7. Try export SAL_NOOPENGL=1 to see if the problem is in your opengl solution
8. Try toggling tools->options->openoffice.org->view->Use hardware acceleration
9. Try export SAL_DISABLE_CAIROTEXT=1

Help Wanted

1. The KDE vclplug is not included, but I have made a src.rpm it is available if someone will volunteer to maintain it (I'll keep it built, but the maintainer must triage kde vcl-plug bugreports to determine what are generic problems, and which are solely kde vclplug only.)
2. Hyphenation rules and dictionaries. There are more Dictionaries and Hyphenation rules available than are currently packaged. I've packaged the ones that were traditionally part of our monolithic OOo package, user experience for some languages may be improved by e.g. adding hyphen-sv etc. packages.