From Fedora Project Wiki

mNo edit summary
No edit summary
Line 9: Line 9:
# When OpenOffice.org releases it's first [http://eis.services.openoffice.org/EIS2/GuestLogon 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.
# When OpenOffice.org releases it's first [http://eis.services.openoffice.org/EIS2/GuestLogon 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.
# 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
# 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
# The Fedora OpenOffice.org rpms '''should''' be split similarly to the upstream rpms, e.g. -core, -base, -writer, the various langpacks, etc
# The Fedora OpenOffice.org structure '''should''' be split similarly to the upstream structure, e.g. -core, -base, -writer, the various langpacks, etc
# The fedora OpenOffice.org tarball '''must''' only be imported by the package maintainer and it should be checked out with [http://people.redhat.com/caolanm/ooocvs/ooocvs ooocvs]  
# The fedora OpenOffice.org tarball '''must''' only be imported by the package maintainer and it should be checked out with [http://people.redhat.com/caolanm/ooocvs/ooocvs ooocvs]  
# Messing with ARCH_FLAGS is a sure way to create a non-functional OpenOffice.org
# Messing with ARCH_FLAGS is a sure way to create a non-functional OpenOffice.org
Line 26: Line 26:
# The langpack '''should''' Require: a [http://wiki.services.openoffice.org/wiki/Dictionary thesaurus]  for the language if available, e.g. mythes-en, mythes-de. See [[OpenOffice.org/LinguisticComponents]]
# The langpack '''should''' Require: a [http://wiki.services.openoffice.org/wiki/Dictionary thesaurus]  for the language if available, e.g. mythes-en, mythes-de. See [[OpenOffice.org/LinguisticComponents]]
# The new langpack '''must''' be added by inserting an appropriate entry into langpackdetails in the .spec.
# The new langpack '''must''' be added by inserting an appropriate entry into langpackdetails in the .spec.
# A langpack '''must''' only be included if there has been an explicit request by someone for it
# Updated translations can be added, but '''must''' be submitted upstream and a request made to include them. (e.g. [https://bugzilla.redhat.com/show_bug.cgi?id=483487 rhbz#483487] request to include upstream [http://qa.openoffice.org/issues/show_bug.cgi?id=98704 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 ==
== OpenOffice.org bug handling guidelines ==
Line 60: Line 62:


# The KDE vclplug is not included, but I have made a src.rpm [https://bugzilla.redhat.com/show_bug.cgi?id=171908 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.)
# The KDE vclplug is not included, but I have made a src.rpm [https://bugzilla.redhat.com/show_bug.cgi?id=171908 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.)
# Hyphenation rules and dictionaries. There are more [http://wiki.services.openoffice.org/wiki/Dictionaries 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.

Revision as of 15:50, 10 March 2009

OpenOffice.org package guidelines

  1. Minimize differences from upstream, ideally we should have no fedora-specific patches at all
  2. All patches must either...
    1. 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
    2. or if the patch or related patchset has been accepted into upstream then name the patch as the workspace name
    3. or if the changes is not upstreamable then contain the fedora bug id in the patch name instead
    4. be aggressively pursued upstream to either get then accepted and merged, or clearly refused
  3. 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.
  4. 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
  5. The Fedora OpenOffice.org structure should be split similarly to the upstream structure, e.g. -core, -base, -writer, the various langpacks, etc
  6. The fedora OpenOffice.org tarball must only be imported by the package maintainer and it should be checked out with ooocvs
  7. 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
  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 new langpack must be added by inserting an appropriate entry into langpackdetails in the .spec.
  8. A langpack must only be included if there has been an explicit request by someone for it
  9. 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

  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.
    1. Print Dialog issues, see if it affects evince as well, -> gtk2
    2. File Dialog issues, see if it affects firefox or eclipse as well -> gtk2
    3. Text Rendering issues, clarify if it is an icu issue, -> icu
    4. Database issues, clarify if it is a hsqldb issue, -> hsqldb
    5. el bizarro bug, clarify if it affects another large c++ program, e.g. firefox -> verify that compilation toolchain is ok
  6. 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=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.)
Retrieved from "https://fedoraproject.org/w/index.php?title=OpenOffice.org&oldid=89430"