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 and added to our upstream fedora applied-patches tracker id if not merged into upstream yet
 * 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 structure should be split similarly to the upstream structure, 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 capable of rendering that language, i.e. Requires: font(:lang=XX)
 * 4) The langpack should Require: a spell-check dictionary for the language if available, e.g. hunspell-en, hunspell-de. See OpenOffice.org/LinguisticComponents
 * 5) The langpack should Require: a hyphenation dictionary  for the language if available, e.g. hyphen-en, hyphen-de. See OpenOffice.org/LinguisticComponents
 * 6) The langpack should Require: a thesaurus  for the language if available, e.g. mythes-en, mythes-de. See OpenOffice.org/LinguisticComponents
 * 7) The langpack should Require: a autocorrect package  for the language if available, e.g. autocorr-en, autocorr-de.
 * 8) The new langpack must be added by inserting an appropriate entry into langpackdetails in the .spec.
 * 9) A langpack must only be included if there has been an explicit request by someone for it
 * 10) Updated translations can be added, but must be submitted upstream and a request made to include them. (e.g. rhbz#483487 request to include upstream i98704 translations) so that we know when we can drop the integrated-upstream translations and don't get sucked into a time-sink translation update churn

OpenOffice.org bug handling guidelines
/etc/cron.daily/prelink rpm -Va
 * 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 (see this fedora wish-list tracker, 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

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=true 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.)