Apache OpenOffice Wiki - User contributions [en]

QA/HowToFileIssue

2014-04-21T20:41:29Z

Talchu: /* Reporting a New Bug */ added some info what happens AFTER an issue is created, so users will feel confident they don't need to notify someone, afterwards.

{{DISPLAYTITLE:How to file a good Issue}}
Yo can find more detailed general instructions [http://www.openoffice.org/qa/issue_handling/basic_rules.html here]
=Principles=

* '''Be precise''', avoid general rare statements like "looks bad", "does not work", but state "indent too big" or "Text stays with alignment 'left' after clicking 'Alignment Centered' icon in standard toolbar" (for example).
* '''Be clear''', don't simply describe what your problem is, explain it so that other users can reproduce the bug
* '''Only one bug per report''', it would be impossible to manage the work flow for multiple bugs fixed by different developers at different times in one bug report.
* '''Only one report per bug''', check for possible DUPlicates, where the problem you observed already has been reported. If you are not sure, add those bugs to ''See Also'' Field with a short comment why you believe your bug might be related to them, or even ''mark as Duplicate''.
* '''No bug is too trivial to report''' - small bugs may hide big bugs
* '''Clearly separate fact from speculation'''

=Preliminaries=

# Reproduce your bug using a recent build of the software, to see whether it has already been fixed.
# Take a snapshot of your screen, to help developers better understand the bug consequences.
# [https://issues.apache.org/ooo/ Create] an AOO Bugzilla account, if you're new to Bugzilla.
# [https://issues.apache.org/ooo/query.cgi?format=specific Search] Apache OOo Bugzilla, to see whether your bug has already been reported.

=Reporting a New Bug=
If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:
# Choose "[https://issues.apache.org/ooo/enter_bug.cgi Enter a new bug]"
# Select the Product in which you've found the bug.
# Fill-out the form (more details below).
# Verify your report, and make sure it's clear, concise, and has no errors or omissions.
# Press "Commit" when done. After you created the issue report, an automated notification will be sent to the [http://openoffice.apache.org/mailing-lists.html#issues-mailing-list ISSUES mailing-list].
# Have patience. It could take time until your issue is noticed, confirmed, and dealt with. If you feel that your bug is being neglected, or that it must be fixed before the next release, send the [http://openoffice.apache.org/mailing-lists.html#development-mailing-list-public DEV mailing-list] a short notice about it.

== Form Fields in Detail ==
'''Component:''' In which sub-part of the software does it exist?

This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, look for a "General" component.

In general the problem can be categorized as following component:

::'''''UI''''': Bug related with UI widget, e.g. menu, toolbar, statusbar, tooltips 
::'''''Open-Import''''': The problem happened while loading document, which you are sure the document has no problem if opened by other product 
::'''''Editing''''': The problem occurred while adding/removing some content of document 
::'''''Save-Export''''': Similar with component "open-import", the problem happened while saving document, the exported document also has problem in other product 

'''Version''': In which version of OpenOffice did you observe the bug, for the first time? 
:Note: When you edit a report you submitted, don't change the version from an older version to a newer one. Version documents the oldest version in which the issue occurred; only experienced community members, primarily QA people, should refine the value, but only in the direction to older versions.

'''Severity''': How severe the bug is

::'''''blocker''''': The bug block other feature/function test. It includes but is not limited to: 
:::Problem does not allow to launch the module access function entry 
:::Problem hinders the creation of documentation 
:::Examples: System crash, application freeze 

::'''''critical''''': The bug make it impossible to work with the version of test on a feature. It includes but is not limited to: 
:::Crash happened intermittently 
:::Problem prevent major test activities 
:::Problem affect other function(not under current testcases) badly 
:::Examples: Application abnormal exist, failure on invoking or triggering the function without any workaround 
::'''''major''''': The bug cause function doesn't work but there is typically workaround. It includes but is not limited to: 
:::A Basic function which, well... doesn't function correctly; 
:::Data loss; 
:::A Crash in special circumstances; 
:::Examples: Cannot rename a sheet, document saved without character font settings. 

::'''''normal''''': Part of a function is workable but there are major faults. It includes but is not limited to: 
:::A bad function result; 
:::A problem has a workaround and can be put off without impacting the functionality; 
:::Examples: Formula export with wrong result, font setting is incorrect. 

::'''''minor''''': The bug does not prevent the work done. It includes but is not limited to: 
:::Spell-check issue in help file; 
:::A problem that is seldom encountered and easy to bypass; 
:::Minor repaint errors; 
:::An nice to have feature; 
:::A Standard keyboard shortcut key doesn't work; 
:::Example: use ctrl+a instead of ctrl+c. 

::'''''trivial''''': The bug might be an (small) enhancement of an existing feature.

'''OS:''' On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.) 
If you know the bug happens on more than one type of operating system, choose ''All''. If your OS isn't listed, choose ''Other''.

'''Summary:''' How would you describe the bug, in approximately 60 or fewer characters? 
A good summary should '''quickly and uniquely identify a bug report'''. It should explain the problem, not your suggested solution.

*Good: "Cancelling a File Copy dialog crashes File Manager"
*Bad: "Software crashes"
*Bad: "Browser should work with my web site"

'''Description:''' The details of your problem report, including:
::''' Overview:''' More detailed restatement of summary. 
:::Application crashed while insert a Chart in Spreadsheet document 
::'''Steps to Reproduce:''' Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps. 
:::# New Spreadsheet document
:::# Insert Chart by menu "Insert->Chart" 
::'''Actual Results:''' What the application did after performing the above steps. 
:::The application crashed. 
::'''Expected Results:''' 
:::Popup Chart Wizard dialog 
::'''Build Date & Platform:''' Date and platform of the build in which you first encountered the bug. 
:::Build: AOO 3.4.1 Rev.1359641
:::OS: Windows XP, Windows 7, SuSE Linux 11 SP1, RedHat Linux 6 Update 3, Ubuntu 12.04... 
::'''Additional Builds and Platforms:''' Whether or not the bug takes place on other platforms 
:::The problem doesn't exist in Mac OS X
::'''Additional Information:''' Any other useful information.
:::Regression info: 
:::The problem doesn't exist in AOO 3.4 Release
::For crashing bugs:
:::Attach the crash log if available.

'''Advnaced field - Issue Type''': Issue type categorized as:
:*Defect
:*Enhancement
:*Feature
:*Patch
:*Task
If the issue is minor, something like nice to have, you can use "Enhancement" as issue type 
If the issue is much complicate to implement, something like feature, you can use "Feature" as issue type

'''Advanced field - Keyword''': Use pre-defined [https://issues.apache.org/ooo/describekeywords.cgi keyword] to tag bug

Available Keywords:

{| class="prettytable"
|-
|
Name

|
Description

|-
|
accessibility

|
Issues referring to the accessibility of the product should have this keyword.

|-
|
accessibility-external

|
This keyword is used for accessibility issues that have to be fixed outside of the Apache OpenOffice code base (eg. Assistive Technology)

|-
|
aqua

|
This keyword should be used to better identify issues applying to a native version (without X11) of OpenOffice.org running on Mac OS X

|-
|
Arabic

|
Referring to the Arabic version.

|-
|
BIDI

|
This keyword marks issues related to bi-directional support

|-
|
CJK

|
If issues are related to Chinese, Japanese and Korean, you can mark it as cjk.

|-
|
crash

|
This keyword can be used for any crash, freeze, hang, that occurs.

|-
|
data_loss

|
Use this keyword for issues that lead to a loss of data (this includes the entire document, the content within a document or loss of configuration settings)

|-
|
easy2dev

|
use this keyword if currently no resources are available to solve this issue and you think this issue would be an doable step in for new volunteers to the project.

|-
|
Hebrew

|
Referring to the Hebrew version.

|-
|
interop_OOXML

|
Keyword denoting interoperability with MSO 2007/2010 file formats based on XML

|-
|
merge_pending

|
request for merging an approved patch into the tree; keyword will be removed by the community member(s) who merge the patch into the tree.

|-
|
ms_interoperability

|
This keyword should be used to identify issues regarding the interoperability with Microsoft Office applications.

|-
|
needhelp

|
This keyword signals somebody seeking assistance. For example, this may be a developer who wants to delegate (parts of) a task, an QA engineer in need for expertise to reproduce a bug, or somebody who wants to verify a patch before integrating it, and needs access to e.g. an exotic Linux distro.

|-
|
needmoreinfo

|
This keyword should be used to mark issues where a QA volunteer or a developer asked the submitter to give more information to an issue. The advantage is that you can query for that keyword and easily figure out where you asked for more information.

|-
|
new_implementation

|
This keyword is used if a new implementation of a component is prepared and helps identifying that this issue refers to new code not yet contained in the installation set.

|-
|
numbering

|
This keyword is used to track issues for outline, numbering and bullet list formatting within the module word processor.

|-
|
odf_validation

|
This keyword is used for issues about ODF documents, written by OpenOffice.org, which do not validate against the latest ODF schema.

|-
|
oooqa

|
This keyword should be used to make clear that an OOo QA volunteer has applied a change to an issue, be it an additional description, a priority change or anything else.

|-
|
performance

|
denotes issues which describe the insufficient performance of a specific task in OpenOffice.org

|-
|
regression

|
This keyword can be set if functionality definately worked in an older version, but doesn't in a newer version. It is very helpful to give detailed information from which version to which version the functionality broke. If this issue is considered a blocker for the next release, the OpenOffice.org team will indicate this by setting the "release_blocker" keyword.

|-
|
release_blocker

|
This keyword denotes issues which are considered a blocker for the next maintanance release (such as 2.0.x).

|-
|
rfe_eval_ok

|
status field for feature request evaluation

|-
|
security

|
Issues referring to security incl. digital signatures, encryption, etc. should have this keyword.

|-
|
third_party_support

|
Issues referring to third party support including groupware and collaboration integration requirement should have this keyword.

|-
|
TSK-DEF

|
Task defined.

|-
|
usability

|
Issues referring to usability and ease of learning should have this keyword.

|-
|
usagetracking

|
Usagetracking issues for Renaissance Project

|}

[[Category:Quality Assurance]]

Issue lifecycle

2014-03-30T08:54:10Z

Talchu: /* Writing an issue (Everyone) */ linked to detailed guide for Bugzilla (issue reporting)

== Writing an issue (Everyone)==
For a detailed guide on how to create an issue, see [[QA/HowToFileIssue]]. Here are some brief notes, though: 
; No support requests : Ask on the [http://incubator.apache.org/openofficeorg/mailing-lists.html#users-mailing-list user mailing list] or [http://ooo-forums.apache.org/en/forum/index.php community forum] to make sure that you do not miss something in handling of AOO. ''ToDo: Add link to support information''
; No duplicates : [https://issues.apache.org/ooo/query.cgi Search in Bugzilla] whether your problem is already reported.
; Reproducible : Write a short and precise description on how to reproduce your problem. In short, document only the essential parts needed to reproduce the problem, in a helpful way. Preferably, attach a screen-shot.

Newly written issues should always have the state "Unconfirmed", if you are the only person, that has worked on it so far, even if you have the rights to set it to "Confirmed".

More info about submitting a bug: http://forum.openoffice.org/en/forum/viewtopic.php?f=74&t=13490

== Make sure it is a valid issue (QA + Developer)==
'''1. Is the description suitable to understand and reproduce the problem?'''

If not, ask the reporter and set keyword "needmoreinfo". If no answer after fourteen days, set the field ''status'' to RESOLVED and the reason to ''IRREPRODUCIBLE''. Comment like "Feel free to reopen the issue, when you can provide the needed information." Submit changes and then set the field ''status'' to CLOSED.

'''2. Make sure AOO is affected.'''
* Is it a support request? Then resolve the issue as ''IRREPRODUCIBLE'' and point the submitter to mailing list and forum.
* Does AOO works as designed, but the reporter expects something different? Set the status to RESOLVED and reason to ''IRREPRODUCIBLE''. Point the reporter to the UX group to discuss, how AOO can be improved to meet user expectations. The reason WONTFIX might be appropriate, if the problem has been discussed recently, and the request was rejected. Point the reporter to the thread. ''ToDo: Add mailing list address or home page of UX on Wiki''
* Is the bug only in a special distribution but not in AOO? In that case resolve the issue with reason ''IRREPRODUCIBLE''. Point the reporter to a suitable issue tracker.

'''3. Has the problem already been reported?'''
* Search not only in field "Summary" but in field "Comment" as well.
* Include closed issues in your search, they might lead you to an active duplicate one.
* The existing issues might have wrong components. Therefor restrict your search only, if you get too many hits.
* Be aware that graphic, image, and picture are used interchangeable by issue reporters. Find other synonymous keywords on [[Synonymous_keywords]].

If you find a duplicate, set field ''status'' to RESOLVED and reason to DUPLICATE. Then you get another field. Enter the number of the duplicate issue there. The other issue gets automatically a link. Submit the changes. Then close the issue.

You are likely to find more than one duplicate. Look, which one has the most votes and/or the best description and close the others with setting "Duplicate".

'''4. Is it a feature request?'''
* Set the the field ''status'' to CONFIRMED and the issue type to ENHANCEMANT or FEATURE.
* Does the feature request contradict the ODF specification? Put this info into your comment and point the reporter to OASIS. Such requests need additional work.
* Examine the fields ''Product'' and ''Component'' and correct them if necessary.
* Has the feature request been discussed or does a specification exists in the Wiki? Put a link to it in the field URL.

In case of a bug report further work is needed.

'''5. Can you reproduce the bug?'''
* If you can reproduce the bug, then examine the fields ''Product'', ''Component'', and ''Issue Type'', and correct them if necessary.
* If your test version is newer than the reported version, select your version from the field ''Latest confirmation on''. Or if you use a developer build, add the revision number in your comment.
* Examine the field ''Platform''. If the reporter has set it to ''all'' but has not mentioned in his description on what platforms (plural!) he has tested, then set the operating system to your system. If you have reproduced the bug on a total different system than the reporter (e.g. reporter WinXP, you MacOS), then set the operating system to ''all'' and mention the systems in your comment.
* Examine the description. Could you reproduce the bug with that description, or could you only reproduce it with playing around? Have you reproduced it with less steps? Give an improved description if necessary.
* If a test document is attached, look whether it is suitable. Often test documents contain much more as needed to reproduce the bug. Remove all things, that not needed. If no test document is attached, but a test document would be helpful, then produce a test document (as small as possible!) and attach it.
* Would a screen shot or a video clip help to understand, what is wrong? Then try to produce them and attach it.
*If you cannot reproduce the bug, the error might depend on the operating system or other environment conditions. Resolve issue with reason ''IRREPRODUCIBLE'', but leave issue open and set keyword "needhelp". If you cannot reproduce the bug using the same environment as the reporter, close the issue.
*In case of import, is AOO able to reflect the mentioned property of the alien document format? Exists this property already in the ODF specification? In case of export, is the alien document format able to reflect the mentioned property of AOO? Include this informations in your comment. Close the bug or made it an enhancement.

'''6. How important is the issue?'''
*Examine the field "Importance". Reporters tend to set it to inappropriate values.
*Does the bug fulfill the criteria for a "release blocker", then not only select "Blocker" but inform the ooo-dev mailing list in addition.
*Crashes and scenarios with data loss in common user actions get at least the importance ''P2 major''.
If unsure about this, use the setting ''P3 normal''.

'''7. Help the developer with additional informations'''
*Minimize the scenario to reproduce the bug.
*Try to reproduce the bug with an older version of AOO or OOo. If you find, that it works there, add the keyword ''regression''.
*If you work on an older, unconfirmed OOo bug and have reproduced it with a new AOO version, select the version in the field ''Latest confirmation on''.
*Do you get additional information by using a debug build?
*In case of a crash, can you produce a backtrace?
*Use keywords and tags in summary to classify the bug. For example for import and export to the Microsoft Office 97 formats the tag WW8: in the summary is used. Also the keyword ''ms_interoperability'' is likely suitable for such import/export problems.

If the issue is still open after all the previous steps, set the status to CONFIRMED.

If you have not the rights to do the suggested changes, then write it as suggestion into the comment.

== Work on the issue (Developer)==
# If you want to fix the issue, set the status to ACCEPTED and assign it to yourself by clicking on "take" in the line "Assigned to".
# You found the root cause, but fixing it will last a while? Then write an intermediate comment. Does the fix depend on the fix for another issue? Then enter the issue number in the field "Depends on".
# You have a fix for the issue but no commit rights or want a review before committing? Generate a patch and attach it to the issue. Make sure you use the type "Patch" in the upload. Set the issue type to PATCH. Inform the ooo-dev list.
# The patch is submitted? Write a comment to the issue, where you reference the revision number. Set the status to RESOLVED with reason FIXED. Do not close the issue.
# In case of a feature request: If you think, it should not be implemented, discuss this on the mailing list and if your opinion gets consensus, set the status to RESOLVED with reason WONTFIX. Explain the reason in the comment and put the link to the discussion in field URL. Close the issue.

== Verify the fix (QA + Developer)==
Use a developer version or a released version which contains the fix and try to reproduce the bug.

If you can no longer reproduce it, comment with "Verified in version <revision number>". If you know areas which might be affected by the fix, test them too. Close the issue.

If you still can reproduce the bug, set the status to REOPEN and explain why.

[[Category:Quality Assurance]]

Quality Assurance

2014-03-30T08:49:29Z

Talchu: /* Issue Tracking */

==General Information==
Quality Assurance (QA) is more than testing! 
You can find some interesting articles about [http://en.wikipedia.org/wiki/Software_quality Software Quality] and [http://en.wikipedia.org/wiki/Software_testing Software Testing] at [http://en.wikipedia.org/wiki/Main_Page WikiPedia].

The Apache OpenOffice community community members working on quality assurance [http://en.wikipedia.org/wiki/Software_quality_assurance (QA)] functions perform important actions for the group effort overall.

If you are interested in doing QA for OpenOffice.org, please feel free, and encouraged, to join the community. You can find all relevant information about joining the team at [http://qa.openoffice.org/ooQAReloaded/Docs/QA-Reloaded-HowToStart.html How-To-Start page].

==Helpful links ==
* Homepage of the QA project on OOo : http://openoffice.apache.org/qa.html
* Mailing list of the QA project:
:Subscribe: mailto:ooo-qa-subscribe@incubator.apache.org
:Archives [http://markmail.org/search/+list:org.apache.incubator.ooo-qa Markmail] [http://mail-archives.apache.org/mod_mbox/incubator-ooo-qa/ Apache]
* Query for existing bugs in IssueTracker : https://issues.apache.org/ooo/
* Writing a new issue in IssueTracker :
:[https://issues.apache.org/ooo/enter_bug.cgi Bugzilla New Issue]
:[[Issue_lifecycle]], a workflow for Bugzilla
* QA category on OOo wiki : [[:Category:Quality_Assurance|Quality Assurance]]
*[[QA/test_automation|Test Automation]]
*[[QA/Build Verification Test(BVT)|Buid Verification Test]]
*[[QA/Performance Verification Test(PVT)|Performance Verification Test]]
*[[Performance/AOO3.4.1_PVT_Introduction]]
*[[QA/SVT | System Verification Test(SVT)]]
*[[QA/SVTReport | SVT/SVT Report]]
*[[QA/AOO341_TestCase/Installation |Installation test cases]]

==Issue Tracking ==
*[[Issue_lifecycle]], a workflow for Bugzilla
*[[QA/HowToFileIssue]], a guide for how to open an issue in Bugzilla.

==Test Case==
'''[http://aootesting.adfinis-sygroup.org/index.php Tool Testlink] is used for test case management:'''
*[[QA/Testcase/How_to_write_test_case |a guide for how to write a test case]],
*[[QA/Testcase/Template |template for test case]],
*[[QA/Testcase/Sample |a sample test case]],
*[[QA/Testlink |a guide for test management]].
*[[QA/Tescase |Database Test Matrix]].
*[[QA/Testcase|General Testing]].

==Automation Test==
* Automation Guide
**[[QA/test_automation_guide|Automation Usage Guide]]
**[[QA/dev_gui_testing | Automation Development Guide]]
**[[QA/vclauto/A_step_by_step_example | GUI Case Development Step by Step Example]]
* BVT(Buid Verification Test)
**[[QA/Build Verification Test(BVT)|Buid Verification Test]]
**[[http://wiki.openoffice.org/wiki/QA/BVT How to run BVT]]
**[[http://wiki.openoffice.org/wiki/QA/BVT_Report BVT Report]]
* PVT(Performance Verification Test)
**[[QA/Performance Verification Test(PVT)|Performance Verification Test]]
**[[Performance/AOO3.4.1_PVT_Introduction]]
**[[http://wiki.openoffice.org/wiki/QA/PVT How to run PVT]]
**[[http://wiki.openoffice.org/wiki/QA/PVT_Report PVT Report]]
* SVT(System Verification Test)
**[[QA/SVT | System Verification Test]]
**[[QA/SVTReport | SVT/SVT Report]]
* FVT(Function Verification Test)
*Automation Todos
**[[QA/FVT/FVTRefactor | FVT Case Refactor]]
**[[QA/Auto/TodoList | Todo WorkList]]

==Routine Test Report==

* [http://people.apache.org/~liuzhe/testdashboard/#bvt Daily Build Verification Test Report]
* [http://people.apache.org/~liuzhe/testdashboard/#pvt Daily Performance Verification Test Report]
* [[QA/Report/FVT |Function Verification Test(FVT)]]
* [[QA/Report/WeeklyReport |Weekly Report]]
* [[QA/Report/DefectStatus |Defect Status Report]]

==Release testing==
===Apache OpenOffice 3.4===
If you have interesting in Apache OpenOffice 3.4 release and plan contribute your QA effort to it, please go to below links for test cases update and testing resul update.
* [http://ci.apache.org/projects/openoffice/install/ AOO 3.4 latest build]:
* [https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots AOO 3.4 Dev Snapshots build]:
* [https://cwiki.apache.org/confluence/display/OOOUSERS/Release-QA-Plan AOO 3.4 test plan]:
* [http://wiki.services.openoffice.org/wiki/QA/TestCases/ AOO 3.4 test cases (in multiple languages)]:
* [http://wiki.services.openoffice.org/wiki/QA/TestResults AOO 3.4 test results]:
* [https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+RC+Build+Test+Plan AOO 3.4 RC Build test plan]
* [https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+RC+Build+Test+Report AOO 3.4 RC Build test result]

===Apache OpenOffice 3.4.1===
If you are interested in Apache OpenOffice 3.4.1 release and plan to contribute your effort on QA work, please go to below link for test case update and test result update
* [https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO3.4.1 AOO 3.4.1 dev snapshot build]:
* [https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Testing+Plan AOO 3.4.1 testing plan]
* [http://wiki.services.openoffice.org/wiki/QA/AOO341_TestCase AOO 3.4.1 test case]
* [http://wiki.services.openoffice.org/wiki/QA/AOO341_TestResult AOO 3.4.1 test result]

:* [http://wiki.services.openoffice.org/wiki/QA/AOO341_GeneralTestingSummary AOO 3.4.1 general testing summary]
:* [http://wiki.services.openoffice.org/wiki/QA/AOO341_InstallationTestingSummary AOO 3.4.1 installation testing summary]

* [https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+RC+Build+Test+Plan AOO 3.4.1 RC build test plan]
* [http://wiki.services.openoffice.org/wiki/QA/AOO341_RC_TestResult AOO 3.4.1 RC build test result]

[[Category:Quality Assurance]]

===Apache OpenOffice 4.0===
* [http://wiki.services.openoffice.org/wiki/QA/AOO40_Database Database General Test]
* [http://wiki.services.openoffice.org/wiki/QA/AOO40_Drawing Drawing General Test]

Talk:Issue lifecycle

2014-03-30T08:46:50Z

Talchu: Suggestion to mention who reviews new issues.

I think this page should mention what happens after an issue has been created. Who review it? who's behind issues@openoffice.org, etc. It's part of the cycle, and and important one to understand, for newbies. --[[User:Talchu|Talchu]] ([[User talk:Talchu|talk]]) 08:46, 30 March 2014 (UTC)

Talk:Quality Assurance

2014-03-30T08:43:59Z

Talchu: Question regarding "IssueTracker" & suggestion to stop using it.

I have removed
:[http://www.openoffice.org/qa/issue_handling/submission_gateway.html Submission Gateway]
because it describes the legacy workflow. If there are parts, which are still useful, they should be moved to the Wiki.

I have added a link to the new page "Issue lifecycle".

What is "IssueTracker"? I suggest to drop using this keyword, and use Bugzilla, or plainly write open an issue and link to the issues subdomain. --[[User:Talchu|Talchu]] ([[User talk:Talchu|talk]]) 08:43, 30 March 2014 (UTC)

QA/HowToFileIssue

2014-03-30T08:38:07Z

Talchu: /* Form Fields in Detail */

{{DISPLAYTITLE:How to file a good Issue}}
Yo can find more detailed general instructions [http://www.openoffice.org/qa/issue_handling/basic_rules.html here]
=Principles=

* '''Be precise''', avoid general rare statements like "looks bad", "does not work", but state "indent too big" or "Text stays with alignment 'left' after clicking 'Alignment Centered' icon in standard toolbar" (for example).
* '''Be clear''', don't simply describe what your problem is, explain it so that other users can reproduce the bug
* '''Only one bug per report''', it would be impossible to manage the work flow for multiple bugs fixed by different developers at different times in one bug report.
* '''Only one report per bug''', check for possible DUPlicates, where the problem you observed already has been reported. If you are not sure, add those bugs to ''See Also'' Field with a short comment why you believe your bug might be related to them, or even ''mark as Duplicate''.
* '''No bug is too trivial to report''' - small bugs may hide big bugs
* '''Clearly separate fact from speculation'''

=Preliminaries=

# Reproduce your bug using a recent build of the software, to see whether it has already been fixed.
# Take a snapshot of your screen, to help developers better understand the bug consequences.
# [https://issues.apache.org/ooo/ Create] an AOO Bugzilla account, if you're new to Bugzilla.
# [https://issues.apache.org/ooo/query.cgi?format=specific Search] Apache OOo Bugzilla, to see whether your bug has already been reported.

=Reporting a New Bug=

If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:

# Choose "[https://issues.apache.org/ooo/enter_bug.cgi Enter a new bug]"
# Select the Product in which you've found the bug.
# Fill out the form (more details below).
# Double-check your report for clarity, errors & omissions, and press "Commit" when done. Your bug report will be added to the Apache OpenOffice Bugzilla database.

== Form Fields in Detail ==
'''Component:''' In which sub-part of the software does it exist?

This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, look for a "General" component.

In general the problem can be categorized as following component:

::'''''UI''''': Bug related with UI widget, e.g. menu, toolbar, statusbar, tooltips 
::'''''Open-Import''''': The problem happened while loading document, which you are sure the document has no problem if opened by other product 
::'''''Editing''''': The problem occurred while adding/removing some content of document 
::'''''Save-Export''''': Similar with component "open-import", the problem happened while saving document, the exported document also has problem in other product 

'''Version''': In which version of OpenOffice did you observe the bug, for the first time? 
:Note: When you edit a report you submitted, don't change the version from an older version to a newer one. Version documents the oldest version in which the issue occurred; only experienced community members, primarily QA people, should refine the value, but only in the direction to older versions.

'''Severity''': How severe the bug is

::'''''blocker''''': The bug block other feature/function test. It includes but is not limited to: 
:::Problem does not allow to launch the module access function entry 
:::Problem hinders the creation of documentation 
:::Examples: System crash, application freeze 

::'''''critical''''': The bug make it impossible to work with the version of test on a feature. It includes but is not limited to: 
:::Crash happened intermittently 
:::Problem prevent major test activities 
:::Problem affect other function(not under current testcases) badly 
:::Examples: Application abnormal exist, failure on invoking or triggering the function without any workaround 
::'''''major''''': The bug cause function doesn't work but there is typically workaround. It includes but is not limited to: 
:::A Basic function which, well... doesn't function correctly; 
:::Data loss; 
:::A Crash in special circumstances; 
:::Examples: Cannot rename a sheet, document saved without character font settings. 

::'''''normal''''': Part of a function is workable but there are major faults. It includes but is not limited to: 
:::A bad function result; 
:::A problem has a workaround and can be put off without impacting the functionality; 
:::Examples: Formula export with wrong result, font setting is incorrect. 

::'''''minor''''': The bug does not prevent the work done. It includes but is not limited to: 
:::Spell-check issue in help file; 
:::A problem that is seldom encountered and easy to bypass; 
:::Minor repaint errors; 
:::An nice to have feature; 
:::A Standard keyboard shortcut key doesn't work; 
:::Example: use ctrl+a instead of ctrl+c. 

::'''''trivial''''': The bug might be an (small) enhancement of an existing feature.

'''OS:''' On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.) 
If you know the bug happens on more than one type of operating system, choose ''All''. If your OS isn't listed, choose ''Other''.

'''Summary:''' How would you describe the bug, in approximately 60 or fewer characters? 
A good summary should '''quickly and uniquely identify a bug report'''. It should explain the problem, not your suggested solution.

*Good: "Cancelling a File Copy dialog crashes File Manager"
*Bad: "Software crashes"
*Bad: "Browser should work with my web site"

'''Description:''' The details of your problem report, including:
::''' Overview:''' More detailed restatement of summary. 
:::Application crashed while insert a Chart in Spreadsheet document 
::'''Steps to Reproduce:''' Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps. 
:::# New Spreadsheet document
:::# Insert Chart by menu "Insert->Chart" 
::'''Actual Results:''' What the application did after performing the above steps. 
:::The application crashed. 
::'''Expected Results:''' 
:::Popup Chart Wizard dialog 
::'''Build Date & Platform:''' Date and platform of the build in which you first encountered the bug. 
:::Build: AOO 3.4.1 Rev.1359641
:::OS: Windows XP, Windows 7, SuSE Linux 11 SP1, RedHat Linux 6 Update 3, Ubuntu 12.04... 
::'''Additional Builds and Platforms:''' Whether or not the bug takes place on other platforms 
:::The problem doesn't exist in Mac OS X
::'''Additional Information:''' Any other useful information.
:::Regression info: 
:::The problem doesn't exist in AOO 3.4 Release
::For crashing bugs:
:::Attach the crash log if available.

'''Advnaced field - Issue Type''': Issue type categorized as:
:*Defect
:*Enhancement
:*Feature
:*Patch
:*Task
If the issue is minor, something like nice to have, you can use "Enhancement" as issue type 
If the issue is much complicate to implement, something like feature, you can use "Feature" as issue type

'''Advanced field - Keyword''': Use pre-defined [https://issues.apache.org/ooo/describekeywords.cgi keyword] to tag bug

Available Keywords:

{| class="prettytable"
|-
|
Name

|
Description

|-
|
accessibility

|
Issues referring to the accessibility of the product should have this keyword.

|-
|
accessibility-external

|
This keyword is used for accessibility issues that have to be fixed outside of the Apache OpenOffice code base (eg. Assistive Technology)

|-
|
aqua

|
This keyword should be used to better identify issues applying to a native version (without X11) of OpenOffice.org running on Mac OS X

|-
|
Arabic

|
Referring to the Arabic version.

|-
|
BIDI

|
This keyword marks issues related to bi-directional support

|-
|
CJK

|
If issues are related to Chinese, Japanese and Korean, you can mark it as cjk.

|-
|
crash

|
This keyword can be used for any crash, freeze, hang, that occurs.

|-
|
data_loss

|
Use this keyword for issues that lead to a loss of data (this includes the entire document, the content within a document or loss of configuration settings)

|-
|
easy2dev

|
use this keyword if currently no resources are available to solve this issue and you think this issue would be an doable step in for new volunteers to the project.

|-
|
Hebrew

|
Referring to the Hebrew version.

|-
|
interop_OOXML

|
Keyword denoting interoperability with MSO 2007/2010 file formats based on XML

|-
|
merge_pending

|
request for merging an approved patch into the tree; keyword will be removed by the community member(s) who merge the patch into the tree.

|-
|
ms_interoperability

|
This keyword should be used to identify issues regarding the interoperability with Microsoft Office applications.

|-
|
needhelp

|
This keyword signals somebody seeking assistance. For example, this may be a developer who wants to delegate (parts of) a task, an QA engineer in need for expertise to reproduce a bug, or somebody who wants to verify a patch before integrating it, and needs access to e.g. an exotic Linux distro.

|-
|
needmoreinfo

|
This keyword should be used to mark issues where a QA volunteer or a developer asked the submitter to give more information to an issue. The advantage is that you can query for that keyword and easily figure out where you asked for more information.

|-
|
new_implementation

|
This keyword is used if a new implementation of a component is prepared and helps identifying that this issue refers to new code not yet contained in the installation set.

|-
|
numbering

|
This keyword is used to track issues for outline, numbering and bullet list formatting within the module word processor.

|-
|
odf_validation

|
This keyword is used for issues about ODF documents, written by OpenOffice.org, which do not validate against the latest ODF schema.

|-
|
oooqa

|
This keyword should be used to make clear that an OOo QA volunteer has applied a change to an issue, be it an additional description, a priority change or anything else.

|-
|
performance

|
denotes issues which describe the insufficient performance of a specific task in OpenOffice.org

|-
|
regression

|
This keyword can be set if functionality definately worked in an older version, but doesn't in a newer version. It is very helpful to give detailed information from which version to which version the functionality broke. If this issue is considered a blocker for the next release, the OpenOffice.org team will indicate this by setting the "release_blocker" keyword.

|-
|
release_blocker

|
This keyword denotes issues which are considered a blocker for the next maintanance release (such as 2.0.x).

|-
|
rfe_eval_ok

|
status field for feature request evaluation

|-
|
security

|
Issues referring to security incl. digital signatures, encryption, etc. should have this keyword.

|-
|
third_party_support

|
Issues referring to third party support including groupware and collaboration integration requirement should have this keyword.

|-
|
TSK-DEF

|
Task defined.

|-
|
usability

|
Issues referring to usability and ease of learning should have this keyword.

|-
|
usagetracking

|
Usagetracking issues for Renaissance Project

|}

[[Category:Quality Assurance]]

QA/HowToFileIssue

2014-03-30T08:33:42Z

Talchu: /* Form Fields in Detail */ Added a note to the Version field, stating NOT to change it after reporting.

{{DISPLAYTITLE:How to file a good Issue}}
Yo can find more detailed general instructions [http://www.openoffice.org/qa/issue_handling/basic_rules.html here]
=Principles=

* '''Be precise''', avoid general rare statements like "looks bad", "does not work", but state "indent too big" or "Text stays with alignment 'left' after clicking 'Alignment Centered' icon in standard toolbar" (for example).
* '''Be clear''', don't simply describe what your problem is, explain it so that other users can reproduce the bug
* '''Only one bug per report''', it would be impossible to manage the work flow for multiple bugs fixed by different developers at different times in one bug report.
* '''Only one report per bug''', check for possible DUPlicates, where the problem you observed already has been reported. If you are not sure, add those bugs to ''See Also'' Field with a short comment why you believe your bug might be related to them, or even ''mark as Duplicate''.
* '''No bug is too trivial to report''' - small bugs may hide big bugs
* '''Clearly separate fact from speculation'''

=Preliminaries=

# Reproduce your bug using a recent build of the software, to see whether it has already been fixed.
# Take a snapshot of your screen, to help developers better understand the bug consequences.
# [https://issues.apache.org/ooo/ Create] an AOO Bugzilla account, if you're new to Bugzilla.
# [https://issues.apache.org/ooo/query.cgi?format=specific Search] Apache OOo Bugzilla, to see whether your bug has already been reported.

=Reporting a New Bug=

If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:

# Choose "[https://issues.apache.org/ooo/enter_bug.cgi Enter a new bug]"
# Select the Product in which you've found the bug.
# Fill out the form (more details below).
# Double-check your report for clarity, errors & omissions, and press "Commit" when done. Your bug report will be added to the Apache OpenOffice Bugzilla database.

== Form Fields in Detail ==
'''Component:''' In which sub-part of the software does it exist?

This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, look for a "General" component.

In general the problem can be categorized as following component:

::'''''UI''''': Bug related with UI widget, e.g. menu, toolbar, statusbar, tooltips 
::'''''Open-Import''''': The problem happened while loading document, which you are sure the document has no problem if opened by other product 
::'''''Editing''''': The problem occurred while adding/removing some content of document 
::'''''Save-Export''''': Similar with component "open-import", the problem happened while saving document, the exported document also has problem in other product 

'''Version''': In which version of OpenOffice did you observe the bug, for the first time? 
Note: When you edit a report you submitted, don't change the version from an older version to a newer one. Version documents the oldest version in which the issue occurred; only experienced community members, primarily QA people, should refine the value, but only in the direction to older versions.

'''Severity''': How severe the bug is

::'''''blocker''''': The bug block other feature/function test. It includes but is not limited to: 
:::Problem does not allow to launch the module access function entry 
:::Problem hinders the creation of documentation 
:::Examples: System crash, application freeze 

::'''''critical''''': The bug make it impossible to work with the version of test on a feature. It includes but is not limited to: 
:::Crash happened intermittently 
:::Problem prevent major test activities 
:::Problem affect other function(not under current testcases) badly 
:::Examples: Application abnormal exist, failure on invoking or triggering the function without any workaround 
::'''''major''''': The bug cause function doesn't work but there is typically workaround. It includes but is not limited to: 
:::A Basic function which, well... doesn't function correctly; 
:::Data loss; 
:::A Crash in special circumstances; 
:::Examples: Cannot rename a sheet, document saved without character font settings. 

::'''''normal''''': Part of a function is workable but there are major faults. It includes but is not limited to: 
:::A bad function result; 
:::A problem has a workaround and can be put off without impacting the functionality; 
:::Examples: Formula export with wrong result, font setting is incorrect. 

::'''''minor''''': The bug does not prevent the work done. It includes but is not limited to: 
:::Spell-check issue in help file; 
:::A problem that is seldom encountered and easy to bypass; 
:::Minor repaint errors; 
:::An nice to have feature; 
:::A Standard keyboard shortcut key doesn't work; 
:::Example: use ctrl+a instead of ctrl+c. 

::'''''trivial''''': The bug might be an (small) enhancement of an existing feature.

'''OS:''' On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.) 
If you know the bug happens on more than one type of operating system, choose ''All''. If your OS isn't listed, choose ''Other''.

'''Summary:''' How would you describe the bug, in approximately 60 or fewer characters? 
A good summary should '''quickly and uniquely identify a bug report'''. It should explain the problem, not your suggested solution.

*Good: "Cancelling a File Copy dialog crashes File Manager"
*Bad: "Software crashes"
*Bad: "Browser should work with my web site"

'''Description:''' The details of your problem report, including:
::''' Overview:''' More detailed restatement of summary. 
:::Application crashed while insert a Chart in Spreadsheet document 
::'''Steps to Reproduce:''' Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps. 
:::# New Spreadsheet document
:::# Insert Chart by menu "Insert->Chart" 
::'''Actual Results:''' What the application did after performing the above steps. 
:::The application crashed. 
::'''Expected Results:''' 
:::Popup Chart Wizard dialog 
::'''Build Date & Platform:''' Date and platform of the build in which you first encountered the bug. 
:::Build: AOO 3.4.1 Rev.1359641
:::OS: Windows XP, Windows 7, SuSE Linux 11 SP1, RedHat Linux 6 Update 3, Ubuntu 12.04... 
::'''Additional Builds and Platforms:''' Whether or not the bug takes place on other platforms 
:::The problem doesn't exist in Mac OS X
::'''Additional Information:''' Any other useful information.
:::Regression info: 
:::The problem doesn't exist in AOO 3.4 Release
::For crashing bugs:
:::Attach the crash log if available.

'''Advnaced field - Issue Type''': Issue type categorized as:
:*Defect
:*Enhancement
:*Feature
:*Patch
:*Task
If the issue is minor, something like nice to have, you can use "Enhancement" as issue type 
If the issue is much complicate to implement, something like feature, you can use "Feature" as issue type

'''Advanced field - Keyword''': Use pre-defined [https://issues.apache.org/ooo/describekeywords.cgi keyword] to tag bug

Available Keywords:

{| class="prettytable"
|-
|
Name

|
Description

|-
|
accessibility

|
Issues referring to the accessibility of the product should have this keyword.

|-
|
accessibility-external

|
This keyword is used for accessibility issues that have to be fixed outside of the Apache OpenOffice code base (eg. Assistive Technology)

|-
|
aqua

|
This keyword should be used to better identify issues applying to a native version (without X11) of OpenOffice.org running on Mac OS X

|-
|
Arabic

|
Referring to the Arabic version.

|-
|
BIDI

|
This keyword marks issues related to bi-directional support

|-
|
CJK

|
If issues are related to Chinese, Japanese and Korean, you can mark it as cjk.

|-
|
crash

|
This keyword can be used for any crash, freeze, hang, that occurs.

|-
|
data_loss

|
Use this keyword for issues that lead to a loss of data (this includes the entire document, the content within a document or loss of configuration settings)

|-
|
easy2dev

|
use this keyword if currently no resources are available to solve this issue and you think this issue would be an doable step in for new volunteers to the project.

|-
|
Hebrew

|
Referring to the Hebrew version.

|-
|
interop_OOXML

|
Keyword denoting interoperability with MSO 2007/2010 file formats based on XML

|-
|
merge_pending

|
request for merging an approved patch into the tree; keyword will be removed by the community member(s) who merge the patch into the tree.

|-
|
ms_interoperability

|
This keyword should be used to identify issues regarding the interoperability with Microsoft Office applications.

|-
|
needhelp

|
This keyword signals somebody seeking assistance. For example, this may be a developer who wants to delegate (parts of) a task, an QA engineer in need for expertise to reproduce a bug, or somebody who wants to verify a patch before integrating it, and needs access to e.g. an exotic Linux distro.

|-
|
needmoreinfo

|
This keyword should be used to mark issues where a QA volunteer or a developer asked the submitter to give more information to an issue. The advantage is that you can query for that keyword and easily figure out where you asked for more information.

|-
|
new_implementation

|
This keyword is used if a new implementation of a component is prepared and helps identifying that this issue refers to new code not yet contained in the installation set.

|-
|
numbering

|
This keyword is used to track issues for outline, numbering and bullet list formatting within the module word processor.

|-
|
odf_validation

|
This keyword is used for issues about ODF documents, written by OpenOffice.org, which do not validate against the latest ODF schema.

|-
|
oooqa

|
This keyword should be used to make clear that an OOo QA volunteer has applied a change to an issue, be it an additional description, a priority change or anything else.

|-
|
performance

|
denotes issues which describe the insufficient performance of a specific task in OpenOffice.org

|-
|
regression

|
This keyword can be set if functionality definately worked in an older version, but doesn't in a newer version. It is very helpful to give detailed information from which version to which version the functionality broke. If this issue is considered a blocker for the next release, the OpenOffice.org team will indicate this by setting the "release_blocker" keyword.

|-
|
release_blocker

|
This keyword denotes issues which are considered a blocker for the next maintanance release (such as 2.0.x).

|-
|
rfe_eval_ok

|
status field for feature request evaluation

|-
|
security

|
Issues referring to security incl. digital signatures, encryption, etc. should have this keyword.

|-
|
third_party_support

|
Issues referring to third party support including groupware and collaboration integration requirement should have this keyword.

|-
|
TSK-DEF

|
Task defined.

|-
|
usability

|
Issues referring to usability and ease of learning should have this keyword.

|-
|
usagetracking

|
Usagetracking issues for Renaissance Project

|}

[[Category:Quality Assurance]]

QA/HowToFileIssue

2014-03-30T07:44:19Z

Talchu: /* Form Fields in Detail */

{{DISPLAYTITLE:How to file a good Issue}}
Yo can find more detailed general instructions [http://www.openoffice.org/qa/issue_handling/basic_rules.html here]
=Principles=

* '''Be precise''', avoid general rare statements like "looks bad", "does not work", but state "indent too big" or "Text stays with alignment 'left' after clicking 'Alignment Centered' icon in standard toolbar" (for example).
* '''Be clear''', don't simply describe what your problem is, explain it so that other users can reproduce the bug
* '''Only one bug per report''', it would be impossible to manage the work flow for multiple bugs fixed by different developers at different times in one bug report.
* '''Only one report per bug''', check for possible DUPlicates, where the problem you observed already has been reported. If you are not sure, add those bugs to ''See Also'' Field with a short comment why you believe your bug might be related to them, or even ''mark as Duplicate''.
* '''No bug is too trivial to report''' - small bugs may hide big bugs
* '''Clearly separate fact from speculation'''

=Preliminaries=

# Reproduce your bug using a recent build of the software, to see whether it has already been fixed.
# Take a snapshot of your screen, to help developers better understand the bug consequences.
# [https://issues.apache.org/ooo/ Create] an AOO Bugzilla account, if you're new to Bugzilla.
# [https://issues.apache.org/ooo/query.cgi?format=specific Search] Apache OOo Bugzilla, to see whether your bug has already been reported.

=Reporting a New Bug=

If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:

# Choose "[https://issues.apache.org/ooo/enter_bug.cgi Enter a new bug]"
# Select the Product in which you've found the bug.
# Fill out the form (more details below).
# Double-check your report for clarity, errors & omissions, and press "Commit" when done. Your bug report will be added to the Apache OpenOffice Bugzilla database.

== Form Fields in Detail ==
'''Component:''' In which sub-part of the software does it exist?

This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, look for a "General" component.

In general the problem can be categorized as following component:

::'''''UI''''': Bug related with UI widget, e.g. menu, toolbar, statusbar, tooltips 
::'''''Open-Import''''': The problem happened while loading document, which you are sure the document has no problem if opened by other product 
::'''''Editing''''': The problem occurred while adding/removing some content of document 
::'''''Save-Export''''': Similar with component "open-import", the problem happened while saving document, the exported document also has problem in other product 

'''Version''': Defect appeared in which release? E.g. AOO 3.4

'''Severity''': How severe the bug is

::'''''blocker''''': The bug block other feature/function test. It includes but is not limited to: 
:::Problem does not allow to launch the module access function entry 
:::Problem hinders the creation of documentation 
:::Examples: System crash, application freeze 

::'''''critical''''': The bug make it impossible to work with the version of test on a feature. It includes but is not limited to: 
:::Crash happened intermittently 
:::Problem prevent major test activities 
:::Problem affect other function(not under current testcases) badly 
:::Examples: Application abnormal exist, failure on invoking or triggering the function without any workaround 
::'''''major''''': The bug cause function doesn't work but there is typically workaround. It includes but is not limited to: 
:::A Basic function which, well... doesn't function correctly; 
:::Data loss; 
:::A Crash in special circumstances; 
:::Examples: Cannot rename a sheet, document saved without character font settings. 

::'''''normal''''': Part of a function is workable but there are major faults. It includes but is not limited to: 
:::A bad function result; 
:::A problem has a workaround and can be put off without impacting the functionality; 
:::Examples: Formula export with wrong result, font setting is incorrect. 

::'''''minor''''': The bug does not prevent the work done. It includes but is not limited to: 
:::Spell-check issue in help file; 
:::A problem that is seldom encountered and easy to bypass; 
:::Minor repaint errors; 
:::An nice to have feature; 
:::A Standard keyboard shortcut key doesn't work; 
:::Example: use ctrl+a instead of ctrl+c. 

::'''''trivial''''': The bug might be an (small) enhancement of an existing feature.

'''OS:''' On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.) 
If you know the bug happens on more than one type of operating system, choose ''All''. If your OS isn't listed, choose ''Other''.

'''Summary:''' How would you describe the bug, in approximately 60 or fewer characters? 
A good summary should '''quickly and uniquely identify a bug report'''. It should explain the problem, not your suggested solution.

*Good: "Cancelling a File Copy dialog crashes File Manager"
*Bad: "Software crashes"
*Bad: "Browser should work with my web site"

'''Description:''' The details of your problem report, including:
::''' Overview:''' More detailed restatement of summary. 
:::Application crashed while insert a Chart in Spreadsheet document 
::'''Steps to Reproduce:''' Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps. 
:::# New Spreadsheet document
:::# Insert Chart by menu "Insert->Chart" 
::'''Actual Results:''' What the application did after performing the above steps. 
:::The application crashed. 
::'''Expected Results:''' 
:::Popup Chart Wizard dialog 
::'''Build Date & Platform:''' Date and platform of the build in which you first encountered the bug. 
:::Build: AOO 3.4.1 Rev.1359641
:::OS: Windows XP, Windows 7, SuSE Linux 11 SP1, RedHat Linux 6 Update 3, Ubuntu 12.04... 
::'''Additional Builds and Platforms:''' Whether or not the bug takes place on other platforms 
:::The problem doesn't exist in Mac OS X
::'''Additional Information:''' Any other useful information.
:::Regression info: 
:::The problem doesn't exist in AOO 3.4 Release
::For crashing bugs:
:::Attach the crash log if available.

'''Advnaced field - Issue Type''': Issue type categorized as:
:*Defect
:*Enhancement
:*Feature
:*Patch
:*Task
If the issue is minor, something like nice to have, you can use "Enhancement" as issue type 
If the issue is much complicate to implement, something like feature, you can use "Feature" as issue type

'''Advanced field - Keyword''': Use pre-defined [https://issues.apache.org/ooo/describekeywords.cgi keyword] to tag bug

Available Keywords:

{| class="prettytable"
|-
|
Name

|
Description

|-
|
accessibility

|
Issues referring to the accessibility of the product should have this keyword.

|-
|
accessibility-external

|
This keyword is used for accessibility issues that have to be fixed outside of the Apache OpenOffice code base (eg. Assistive Technology)

|-
|
aqua

|
This keyword should be used to better identify issues applying to a native version (without X11) of OpenOffice.org running on Mac OS X

|-
|
Arabic

|
Referring to the Arabic version.

|-
|
BIDI

|
This keyword marks issues related to bi-directional support

|-
|
CJK

|
If issues are related to Chinese, Japanese and Korean, you can mark it as cjk.

|-
|
crash

|
This keyword can be used for any crash, freeze, hang, that occurs.

|-
|
data_loss

|
Use this keyword for issues that lead to a loss of data (this includes the entire document, the content within a document or loss of configuration settings)

|-
|
easy2dev

|
use this keyword if currently no resources are available to solve this issue and you think this issue would be an doable step in for new volunteers to the project.

|-
|
Hebrew

|
Referring to the Hebrew version.

|-
|
interop_OOXML

|
Keyword denoting interoperability with MSO 2007/2010 file formats based on XML

|-
|
merge_pending

|
request for merging an approved patch into the tree; keyword will be removed by the community member(s) who merge the patch into the tree.

|-
|
ms_interoperability

|
This keyword should be used to identify issues regarding the interoperability with Microsoft Office applications.

|-
|
needhelp

|
This keyword signals somebody seeking assistance. For example, this may be a developer who wants to delegate (parts of) a task, an QA engineer in need for expertise to reproduce a bug, or somebody who wants to verify a patch before integrating it, and needs access to e.g. an exotic Linux distro.

|-
|
needmoreinfo

|
This keyword should be used to mark issues where a QA volunteer or a developer asked the submitter to give more information to an issue. The advantage is that you can query for that keyword and easily figure out where you asked for more information.

|-
|
new_implementation

|
This keyword is used if a new implementation of a component is prepared and helps identifying that this issue refers to new code not yet contained in the installation set.

|-
|
numbering

|
This keyword is used to track issues for outline, numbering and bullet list formatting within the module word processor.

|-
|
odf_validation

|
This keyword is used for issues about ODF documents, written by OpenOffice.org, which do not validate against the latest ODF schema.

|-
|
oooqa

|
This keyword should be used to make clear that an OOo QA volunteer has applied a change to an issue, be it an additional description, a priority change or anything else.

|-
|
performance

|
denotes issues which describe the insufficient performance of a specific task in OpenOffice.org

|-
|
regression

|
This keyword can be set if functionality definately worked in an older version, but doesn't in a newer version. It is very helpful to give detailed information from which version to which version the functionality broke. If this issue is considered a blocker for the next release, the OpenOffice.org team will indicate this by setting the "release_blocker" keyword.

|-
|
release_blocker

|
This keyword denotes issues which are considered a blocker for the next maintanance release (such as 2.0.x).

|-
|
rfe_eval_ok

|
status field for feature request evaluation

|-
|
security

|
Issues referring to security incl. digital signatures, encryption, etc. should have this keyword.

|-
|
third_party_support

|
Issues referring to third party support including groupware and collaboration integration requirement should have this keyword.

|-
|
TSK-DEF

|
Task defined.

|-
|
usability

|
Issues referring to usability and ease of learning should have this keyword.

|-
|
usagetracking

|
Usagetracking issues for Renaissance Project

|}

[[Category:Quality Assurance]]

QA/HowToFileIssue

2014-03-30T07:37:22Z

Talchu: /* Reporting a New Bug */ added a list item, and heading for form details.

{{DISPLAYTITLE:How to file a good Issue}}
Yo can find more detailed general instructions [http://www.openoffice.org/qa/issue_handling/basic_rules.html here]
=Principles=

* '''Be precise''', avoid general rare statements like "looks bad", "does not work", but state "indent too big" or "Text stays with alignment 'left' after clicking 'Alignment Centered' icon in standard toolbar" (for example).
* '''Be clear''', don't simply describe what your problem is, explain it so that other users can reproduce the bug
* '''Only one bug per report''', it would be impossible to manage the work flow for multiple bugs fixed by different developers at different times in one bug report.
* '''Only one report per bug''', check for possible DUPlicates, where the problem you observed already has been reported. If you are not sure, add those bugs to ''See Also'' Field with a short comment why you believe your bug might be related to them, or even ''mark as Duplicate''.
* '''No bug is too trivial to report''' - small bugs may hide big bugs
* '''Clearly separate fact from speculation'''

=Preliminaries=

# Reproduce your bug using a recent build of the software, to see whether it has already been fixed.
# Take a snapshot of your screen, to help developers better understand the bug consequences.
# [https://issues.apache.org/ooo/ Create] an AOO Bugzilla account, if you're new to Bugzilla.
# [https://issues.apache.org/ooo/query.cgi?format=specific Search] Apache OOo Bugzilla, to see whether your bug has already been reported.

=Reporting a New Bug=

If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:

# Choose "[https://issues.apache.org/ooo/enter_bug.cgi Enter a new bug]"
# Select the Product in which you've found the bug.
# Fill out the form (more details below).
# Double-check your report for clarity, errors & omissions, and press "Commit" when done. Your bug report will be added to the Apache OpenOffice Bugzilla database.

== Form Fields in Detail ==
'''Component:''' In which sub-part of the software does it exist?

This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, look for a "General" component.

In general the problem can be categorized as following component:

::'''''UI''''': Bug related with UI widget, e.g. menu, toolbar, statusbar, tooltips 
::'''''Open-Import''''': The problem happened while loading document, which you are sure the document has no problem if opened by other product 
::'''''Editing''''': The problem occurred while adding/removing some content of document 
::'''''Save-Export''''': Similar with component "open-import", the problem happened while saving document, the exported document also has problem in other product 

'''Version''': Defect appeared in which release? E.g. AOO 3.4

'''Severity''': How severe the bug is

::'''''blocker''''': The bug block other feature/function test. It includes but is not limited to: 
:::Problem does not allow to launch the module access function entry 
:::Problem hinders the creation of documentation 
:::Examples: System crash, application freeze 

::'''''critical''''': The bug make it impossible to work with the version of test on a feature. It includes but is not limited to: 
:::Crash happened intermittently 
:::Problem prevent major test activities 
:::Problem affect other function(not under current testcases) badly 
:::Examples: Application abnormal exist, failure on invoking or triggering the function without any workaround 
::'''''major''''': The bug cause function doesn't work but there is typically workaround. It includes but is not limited to: 
:::Basic function doesn't work correctly 
:::Data lost 
:::Crash in special circumstances 
:::Examples: Cannot rename a sheet, document saved without character font setting 

::'''''normal''''': Part of function is workable but there are major fault. It includes but is not limited to: 
:::Bad function result 
:::Problem has workaround and can be put off without impacting the functionality 
:::Examples: Formula export with wrong result, font setting is incorrect 

::'''''minor''''': The bug does not prevent the work done. It includes but is not limited to: 
:::Spell check issue in help file 
:::Problem that is seldom encountered and easy to bypass 
:::Minor repaint errors 
:::Nice to have feature 
:::Standard keyboard shortcut key doesn't work 
:::Example: use ctrl+a instead of ctrl+c 

::'''''trivial''''': The bug might be an enhancement of feature

'''OS:''' On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.) 
If you know the bug happens on more than one type of operating system, choose ''All''. If your OS isn't listed, choose ''Other''.

'''Summary:''' How would you describe the bug, in approximately 60 or fewer characters? 
A good summary should '''quickly and uniquely identify a bug report'''. It should explain the problem, not your suggested solution.

*Good: "Cancelling a File Copy dialog crashes File Manager"
*Bad: "Software crashes"
*Bad: "Browser should work with my web site"

'''Description:''' The details of your problem report, including:
::''' Overview:''' More detailed restatement of summary. 
:::Application crashed while insert a Chart in Spreadsheet document 
::'''Steps to Reproduce:''' Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps. 
:::# New Spreadsheet document
:::# Insert Chart by menu "Insert->Chart" 
::'''Actual Results:''' What the application did after performing the above steps. 
:::The application crashed. 
::'''Expected Results:''' 
:::Popup Chart Wizard dialog 
::'''Build Date & Platform:''' Date and platform of the build in which you first encountered the bug. 
:::Build: AOO 3.4.1 Rev.1359641
:::OS: Windows XP, Windows 7, SuSE Linux 11 SP1, RedHat Linux 6 Update 3, Ubuntu 12.04... 
::'''Additional Builds and Platforms:''' Whether or not the bug takes place on other platforms 
:::The problem doesn't exist in Mac OS X
::'''Additional Information:''' Any other useful information.
:::Regression info: 
:::The problem doesn't exist in AOO 3.4 Release
::For crashing bugs:
:::Attach the crash log if available.

'''Advnaced field - Issue Type''': Issue type categorized as:
:*Defect
:*Enhancement
:*Feature
:*Patch
:*Task
If the issue is minor, something like nice to have, you can use "Enhancement" as issue type 
If the issue is much complicate to implement, something like feature, you can use "Feature" as issue type

'''Advanced field - Keyword''': Use pre-defined [https://issues.apache.org/ooo/describekeywords.cgi keyword] to tag bug

Available Keywords:

{| class="prettytable"
|-
|
Name

|
Description

|-
|
accessibility

|
Issues referring to the accessibility of the product should have this keyword.

|-
|
accessibility-external

|
This keyword is used for accessibility issues that have to be fixed outside of the Apache OpenOffice code base (eg. Assistive Technology)

|-
|
aqua

|
This keyword should be used to better identify issues applying to a native version (without X11) of OpenOffice.org running on Mac OS X

|-
|
Arabic

|
Referring to the Arabic version.

|-
|
BIDI

|
This keyword marks issues related to bi-directional support

|-
|
CJK

|
If issues are related to Chinese, Japanese and Korean, you can mark it as cjk.

|-
|
crash

|
This keyword can be used for any crash, freeze, hang, that occurs.

|-
|
data_loss

|
Use this keyword for issues that lead to a loss of data (this includes the entire document, the content within a document or loss of configuration settings)

|-
|
easy2dev

|
use this keyword if currently no resources are available to solve this issue and you think this issue would be an doable step in for new volunteers to the project.

|-
|
Hebrew

|
Referring to the Hebrew version.

|-
|
interop_OOXML

|
Keyword denoting interoperability with MSO 2007/2010 file formats based on XML

|-
|
merge_pending

|
request for merging an approved patch into the tree; keyword will be removed by the community member(s) who merge the patch into the tree.

|-
|
ms_interoperability

|
This keyword should be used to identify issues regarding the interoperability with Microsoft Office applications.

|-
|
needhelp

|
This keyword signals somebody seeking assistance. For example, this may be a developer who wants to delegate (parts of) a task, an QA engineer in need for expertise to reproduce a bug, or somebody who wants to verify a patch before integrating it, and needs access to e.g. an exotic Linux distro.

|-
|
needmoreinfo

|
This keyword should be used to mark issues where a QA volunteer or a developer asked the submitter to give more information to an issue. The advantage is that you can query for that keyword and easily figure out where you asked for more information.

|-
|
new_implementation

|
This keyword is used if a new implementation of a component is prepared and helps identifying that this issue refers to new code not yet contained in the installation set.

|-
|
numbering

|
This keyword is used to track issues for outline, numbering and bullet list formatting within the module word processor.

|-
|
odf_validation

|
This keyword is used for issues about ODF documents, written by OpenOffice.org, which do not validate against the latest ODF schema.

|-
|
oooqa

|
This keyword should be used to make clear that an OOo QA volunteer has applied a change to an issue, be it an additional description, a priority change or anything else.

|-
|
performance

|
denotes issues which describe the insufficient performance of a specific task in OpenOffice.org

|-
|
regression

|
This keyword can be set if functionality definately worked in an older version, but doesn't in a newer version. It is very helpful to give detailed information from which version to which version the functionality broke. If this issue is considered a blocker for the next release, the OpenOffice.org team will indicate this by setting the "release_blocker" keyword.

|-
|
release_blocker

|
This keyword denotes issues which are considered a blocker for the next maintanance release (such as 2.0.x).

|-
|
rfe_eval_ok

|
status field for feature request evaluation

|-
|
security

|
Issues referring to security incl. digital signatures, encryption, etc. should have this keyword.

|-
|
third_party_support

|
Issues referring to third party support including groupware and collaboration integration requirement should have this keyword.

|-
|
TSK-DEF

|
Task defined.

|-
|
usability

|
Issues referring to usability and ease of learning should have this keyword.

|-
|
usagetracking

|
Usagetracking issues for Renaissance Project

|}

[[Category:Quality Assurance]]

QA/HowToFileIssue

2014-03-30T07:26:25Z

Talchu: /* Preliminaries */

{{DISPLAYTITLE:How to file a good Issue}}
Yo can find more detailed general instructions [http://www.openoffice.org/qa/issue_handling/basic_rules.html here]
=Principles=

* '''Be precise''', avoid general rare statements like "looks bad", "does not work", but state "indent too big" or "Text stays with alignment 'left' after clicking 'Alignment Centered' icon in standard toolbar" (for example).
* '''Be clear''', don't simply describe what your problem is, explain it so that other users can reproduce the bug
* '''Only one bug per report''', it would be impossible to manage the work flow for multiple bugs fixed by different developers at different times in one bug report.
* '''Only one report per bug''', check for possible DUPlicates, where the problem you observed already has been reported. If you are not sure, add those bugs to ''See Also'' Field with a short comment why you believe your bug might be related to them, or even ''mark as Duplicate''.
* '''No bug is too trivial to report''' - small bugs may hide big bugs
* '''Clearly separate fact from speculation'''

=Preliminaries=

# Reproduce your bug using a recent build of the software, to see whether it has already been fixed.
# Take a snapshot of your screen, to help developers better understand the bug consequences.
# [https://issues.apache.org/ooo/ Create] an AOO Bugzilla account, if you're new to Bugzilla.
# [https://issues.apache.org/ooo/query.cgi?format=specific Search] Apache OOo Bugzilla, to see whether your bug has already been reported.

=Reporting a New Bug=

If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:

# Choose "[https://issues.apache.org/ooo/enter_bug.cgi Enter a new bug]"
# Select the product in which you've found the bug
# Fill out the form. Here is some help understanding it:

'''Component:''' In which sub-part of the software does it exist?

This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, look for a "General" component.

In general the problem can be categorized as following component:

::'''''UI''''': Bug related with UI widget, e.g. menu, toolbar, statusbar, tooltips 
::'''''Open-Import''''': The problem happened while loading document, which you are sure the document has no problem if opened by other product 
::'''''Editing''''': The problem occurred while adding/removing some content of document 
::'''''Save-Export''''': Similar with component "open-import", the problem happened while saving document, the exported document also has problem in other product 

'''Version''': Defect appeared in which release? E.g. AOO 3.4

'''Severity''': How severe the bug is

::'''''blocker''''': The bug block other feature/function test. It includes but is not limited to: 
:::Problem does not allow to launch the module access function entry 
:::Problem hinders the creation of documentation 
:::Examples: System crash, application freeze 

::'''''critical''''': The bug make it impossible to work with the version of test on a feature. It includes but is not limited to: 
:::Crash happened intermittently 
:::Problem prevent major test activities 
:::Problem affect other function(not under current testcases) badly 
:::Examples: Application abnormal exist, failure on invoking or triggering the function without any workaround 
::'''''major''''': The bug cause function doesn't work but there is typically workaround. It includes but is not limited to: 
:::Basic function doesn't work correctly 
:::Data lost 
:::Crash in special circumstances 
:::Examples: Cannot rename a sheet, document saved without character font setting 

::'''''normal''''': Part of function is workable but there are major fault. It includes but is not limited to: 
:::Bad function result 
:::Problem has workaround and can be put off without impacting the functionality 
:::Examples: Formula export with wrong result, font setting is incorrect 

::'''''minor''''': The bug does not prevent the work done. It includes but is not limited to: 
:::Spell check issue in help file 
:::Problem that is seldom encountered and easy to bypass 
:::Minor repaint errors 
:::Nice to have feature 
:::Standard keyboard shortcut key doesn't work 
:::Example: use ctrl+a instead of ctrl+c 

::'''''trivial''''': The bug might be an enhancement of feature

'''OS:''' On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.) 
If you know the bug happens on more than one type of operating system, choose ''All''. If your OS isn't listed, choose ''Other''.

'''Summary:''' How would you describe the bug, in approximately 60 or fewer characters? 
A good summary should '''quickly and uniquely identify a bug report'''. It should explain the problem, not your suggested solution.

*Good: "Cancelling a File Copy dialog crashes File Manager"
*Bad: "Software crashes"
*Bad: "Browser should work with my web site"

'''Description:''' The details of your problem report, including:
::''' Overview:''' More detailed restatement of summary. 
:::Application crashed while insert a Chart in Spreadsheet document 
::'''Steps to Reproduce:''' Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps. 
:::# New Spreadsheet document
:::# Insert Chart by menu "Insert->Chart" 
::'''Actual Results:''' What the application did after performing the above steps. 
:::The application crashed. 
::'''Expected Results:''' 
:::Popup Chart Wizard dialog 
::'''Build Date & Platform:''' Date and platform of the build in which you first encountered the bug. 
:::Build: AOO 3.4.1 Rev.1359641
:::OS: Windows XP, Windows 7, SuSE Linux 11 SP1, RedHat Linux 6 Update 3, Ubuntu 12.04... 
::'''Additional Builds and Platforms:''' Whether or not the bug takes place on other platforms 
:::The problem doesn't exist in Mac OS X
::'''Additional Information:''' Any other useful information.
:::Regression info: 
:::The problem doesn't exist in AOO 3.4 Release
::For crashing bugs:
:::Attach the crash log if available.

'''Advnaced field - Issue Type''': Issue type categorized as:
:*Defect
:*Enhancement
:*Feature
:*Patch
:*Task
If the issue is minor, something like nice to have, you can use "Enhancement" as issue type 
If the issue is much complicate to implement, something like feature, you can use "Feature" as issue type

'''Advanced field - Keyword''': Use pre-defined [https://issues.apache.org/ooo/describekeywords.cgi keyword] to tag bug

Available Keywords:

{| class="prettytable"
|-
|
Name

|
Description

|-
|
accessibility

|
Issues referring to the accessibility of the product should have this keyword.

|-
|
accessibility-external

|
This keyword is used for accessibility issues that have to be fixed outside of the Apache OpenOffice code base (eg. Assistive Technology)

|-
|
aqua

|
This keyword should be used to better identify issues applying to a native version (without X11) of OpenOffice.org running on Mac OS X

|-
|
Arabic

|
Referring to the Arabic version.

|-
|
BIDI

|
This keyword marks issues related to bi-directional support

|-
|
CJK

|
If issues are related to Chinese, Japanese and Korean, you can mark it as cjk.

|-
|
crash

|
This keyword can be used for any crash, freeze, hang, that occurs.

|-
|
data_loss

|
Use this keyword for issues that lead to a loss of data (this includes the entire document, the content within a document or loss of configuration settings)

|-
|
easy2dev

|
use this keyword if currently no resources are available to solve this issue and you think this issue would be an doable step in for new volunteers to the project.

|-
|
Hebrew

|
Referring to the Hebrew version.

|-
|
interop_OOXML

|
Keyword denoting interoperability with MSO 2007/2010 file formats based on XML

|-
|
merge_pending

|
request for merging an approved patch into the tree; keyword will be removed by the community member(s) who merge the patch into the tree.

|-
|
ms_interoperability

|
This keyword should be used to identify issues regarding the interoperability with Microsoft Office applications.

|-
|
needhelp

|
This keyword signals somebody seeking assistance. For example, this may be a developer who wants to delegate (parts of) a task, an QA engineer in need for expertise to reproduce a bug, or somebody who wants to verify a patch before integrating it, and needs access to e.g. an exotic Linux distro.

|-
|
needmoreinfo

|
This keyword should be used to mark issues where a QA volunteer or a developer asked the submitter to give more information to an issue. The advantage is that you can query for that keyword and easily figure out where you asked for more information.

|-
|
new_implementation

|
This keyword is used if a new implementation of a component is prepared and helps identifying that this issue refers to new code not yet contained in the installation set.

|-
|
numbering

|
This keyword is used to track issues for outline, numbering and bullet list formatting within the module word processor.

|-
|
odf_validation

|
This keyword is used for issues about ODF documents, written by OpenOffice.org, which do not validate against the latest ODF schema.

|-
|
oooqa

|
This keyword should be used to make clear that an OOo QA volunteer has applied a change to an issue, be it an additional description, a priority change or anything else.

|-
|
performance

|
denotes issues which describe the insufficient performance of a specific task in OpenOffice.org

|-
|
regression

|
This keyword can be set if functionality definately worked in an older version, but doesn't in a newer version. It is very helpful to give detailed information from which version to which version the functionality broke. If this issue is considered a blocker for the next release, the OpenOffice.org team will indicate this by setting the "release_blocker" keyword.

|-
|
release_blocker

|
This keyword denotes issues which are considered a blocker for the next maintanance release (such as 2.0.x).

|-
|
rfe_eval_ok

|
status field for feature request evaluation

|-
|
security

|
Issues referring to security incl. digital signatures, encryption, etc. should have this keyword.

|-
|
third_party_support

|
Issues referring to third party support including groupware and collaboration integration requirement should have this keyword.

|-
|
TSK-DEF

|
Task defined.

|-
|
usability

|
Issues referring to usability and ease of learning should have this keyword.

|-
|
usagetracking

|
Usagetracking issues for Renaissance Project

|}

Double-check your report for errors and omissions, then press "Commit". Your bug report will now be in the Apache OOo Bugzilla database.

[[Category:Quality Assurance]]

QA/HowToFileIssue

2014-03-30T07:20:29Z

Talchu:

{{DISPLAYTITLE:How to file a good Issue}}
Yo can find more detailed general instructions [http://www.openoffice.org/qa/issue_handling/basic_rules.html here]
=Principles=

* '''Be precise''', avoid general rare statements like "looks bad", "does not work", but state "indent too big" or "Text stays with alignment 'left' after clicking 'Alignment Centered' icon in standard toolbar" (for example).
* '''Be clear''', don't simply describe what your problem is, explain it so that other users can reproduce the bug
* '''Only one bug per report''', it would be impossible to manage the work flow for multiple bugs fixed by different developers at different times in one bug report.
* '''Only one report per bug''', check for possible DUPlicates, where the problem you observed already has been reported. If you are not sure, add those bugs to ''See Also'' Field with a short comment why you believe your bug might be related to them, or even ''mark as Duplicate''.
* '''No bug is too trivial to report''' - small bugs may hide big bugs
* '''Clearly separate fact from speculation'''

=Preliminaries=

# Reproduce your bug using a recent build of the software, to see whether it has already been fixed.
# Register account in Apache OOo Bugzilla
# [https://issues.apache.org/ooo/query.cgi?format=specific Search] Apache OOo Bugzilla, to see whether your bug has already been reported.

=Reporting a New Bug=

If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:

# Choose "[https://issues.apache.org/ooo/enter_bug.cgi Enter a new bug]"
# Select the product in which you've found the bug
# Fill out the form. Here is some help understanding it:

'''Component:''' In which sub-part of the software does it exist?

This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, look for a "General" component.

In general the problem can be categorized as following component:

::'''''UI''''': Bug related with UI widget, e.g. menu, toolbar, statusbar, tooltips 
::'''''Open-Import''''': The problem happened while loading document, which you are sure the document has no problem if opened by other product 
::'''''Editing''''': The problem occurred while adding/removing some content of document 
::'''''Save-Export''''': Similar with component "open-import", the problem happened while saving document, the exported document also has problem in other product 

'''Version''': Defect appeared in which release? E.g. AOO 3.4

'''Severity''': How severe the bug is

::'''''blocker''''': The bug block other feature/function test. It includes but is not limited to: 
:::Problem does not allow to launch the module access function entry 
:::Problem hinders the creation of documentation 
:::Examples: System crash, application freeze 

::'''''critical''''': The bug make it impossible to work with the version of test on a feature. It includes but is not limited to: 
:::Crash happened intermittently 
:::Problem prevent major test activities 
:::Problem affect other function(not under current testcases) badly 
:::Examples: Application abnormal exist, failure on invoking or triggering the function without any workaround 
::'''''major''''': The bug cause function doesn't work but there is typically workaround. It includes but is not limited to: 
:::Basic function doesn't work correctly 
:::Data lost 
:::Crash in special circumstances 
:::Examples: Cannot rename a sheet, document saved without character font setting 

::'''''normal''''': Part of function is workable but there are major fault. It includes but is not limited to: 
:::Bad function result 
:::Problem has workaround and can be put off without impacting the functionality 
:::Examples: Formula export with wrong result, font setting is incorrect 

::'''''minor''''': The bug does not prevent the work done. It includes but is not limited to: 
:::Spell check issue in help file 
:::Problem that is seldom encountered and easy to bypass 
:::Minor repaint errors 
:::Nice to have feature 
:::Standard keyboard shortcut key doesn't work 
:::Example: use ctrl+a instead of ctrl+c 

::'''''trivial''''': The bug might be an enhancement of feature

'''OS:''' On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.) 
If you know the bug happens on more than one type of operating system, choose ''All''. If your OS isn't listed, choose ''Other''.

'''Summary:''' How would you describe the bug, in approximately 60 or fewer characters? 
A good summary should '''quickly and uniquely identify a bug report'''. It should explain the problem, not your suggested solution.

*Good: "Cancelling a File Copy dialog crashes File Manager"
*Bad: "Software crashes"
*Bad: "Browser should work with my web site"

'''Description:''' The details of your problem report, including:
::''' Overview:''' More detailed restatement of summary. 
:::Application crashed while insert a Chart in Spreadsheet document 
::'''Steps to Reproduce:''' Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps. 
:::# New Spreadsheet document
:::# Insert Chart by menu "Insert->Chart" 
::'''Actual Results:''' What the application did after performing the above steps. 
:::The application crashed. 
::'''Expected Results:''' 
:::Popup Chart Wizard dialog 
::'''Build Date & Platform:''' Date and platform of the build in which you first encountered the bug. 
:::Build: AOO 3.4.1 Rev.1359641
:::OS: Windows XP, Windows 7, SuSE Linux 11 SP1, RedHat Linux 6 Update 3, Ubuntu 12.04... 
::'''Additional Builds and Platforms:''' Whether or not the bug takes place on other platforms 
:::The problem doesn't exist in Mac OS X
::'''Additional Information:''' Any other useful information.
:::Regression info: 
:::The problem doesn't exist in AOO 3.4 Release
::For crashing bugs:
:::Attach the crash log if available.

'''Advnaced field - Issue Type''': Issue type categorized as:
:*Defect
:*Enhancement
:*Feature
:*Patch
:*Task
If the issue is minor, something like nice to have, you can use "Enhancement" as issue type 
If the issue is much complicate to implement, something like feature, you can use "Feature" as issue type

'''Advanced field - Keyword''': Use pre-defined [https://issues.apache.org/ooo/describekeywords.cgi keyword] to tag bug

Available Keywords:

{| class="prettytable"
|-
|
Name

|
Description

|-
|
accessibility

|
Issues referring to the accessibility of the product should have this keyword.

|-
|
accessibility-external

|
This keyword is used for accessibility issues that have to be fixed outside of the Apache OpenOffice code base (eg. Assistive Technology)

|-
|
aqua

|
This keyword should be used to better identify issues applying to a native version (without X11) of OpenOffice.org running on Mac OS X

|-
|
Arabic

|
Referring to the Arabic version.

|-
|
BIDI

|
This keyword marks issues related to bi-directional support

|-
|
CJK

|
If issues are related to Chinese, Japanese and Korean, you can mark it as cjk.

|-
|
crash

|
This keyword can be used for any crash, freeze, hang, that occurs.

|-
|
data_loss

|
Use this keyword for issues that lead to a loss of data (this includes the entire document, the content within a document or loss of configuration settings)

|-
|
easy2dev

|
use this keyword if currently no resources are available to solve this issue and you think this issue would be an doable step in for new volunteers to the project.

|-
|
Hebrew

|
Referring to the Hebrew version.

|-
|
interop_OOXML

|
Keyword denoting interoperability with MSO 2007/2010 file formats based on XML

|-
|
merge_pending

|
request for merging an approved patch into the tree; keyword will be removed by the community member(s) who merge the patch into the tree.

|-
|
ms_interoperability

|
This keyword should be used to identify issues regarding the interoperability with Microsoft Office applications.

|-
|
needhelp

|
This keyword signals somebody seeking assistance. For example, this may be a developer who wants to delegate (parts of) a task, an QA engineer in need for expertise to reproduce a bug, or somebody who wants to verify a patch before integrating it, and needs access to e.g. an exotic Linux distro.

|-
|
needmoreinfo

|
This keyword should be used to mark issues where a QA volunteer or a developer asked the submitter to give more information to an issue. The advantage is that you can query for that keyword and easily figure out where you asked for more information.

|-
|
new_implementation

|
This keyword is used if a new implementation of a component is prepared and helps identifying that this issue refers to new code not yet contained in the installation set.

|-
|
numbering

|
This keyword is used to track issues for outline, numbering and bullet list formatting within the module word processor.

|-
|
odf_validation

|
This keyword is used for issues about ODF documents, written by OpenOffice.org, which do not validate against the latest ODF schema.

|-
|
oooqa

|
This keyword should be used to make clear that an OOo QA volunteer has applied a change to an issue, be it an additional description, a priority change or anything else.

|-
|
performance

|
denotes issues which describe the insufficient performance of a specific task in OpenOffice.org

|-
|
regression

|
This keyword can be set if functionality definately worked in an older version, but doesn't in a newer version. It is very helpful to give detailed information from which version to which version the functionality broke. If this issue is considered a blocker for the next release, the OpenOffice.org team will indicate this by setting the "release_blocker" keyword.

|-
|
release_blocker

|
This keyword denotes issues which are considered a blocker for the next maintanance release (such as 2.0.x).

|-
|
rfe_eval_ok

|
status field for feature request evaluation

|-
|
security

|
Issues referring to security incl. digital signatures, encryption, etc. should have this keyword.

|-
|
third_party_support

|
Issues referring to third party support including groupware and collaboration integration requirement should have this keyword.

|-
|
TSK-DEF

|
Task defined.

|-
|
usability

|
Issues referring to usability and ease of learning should have this keyword.

|-
|
usagetracking

|
Usagetracking issues for Renaissance Project

|}

Double-check your report for errors and omissions, then press "Commit". Your bug report will now be in the Apache OOo Bugzilla database.

[[Category:Quality Assurance]]

Talk:QA/HowToFileIssue

2014-03-29T19:02:05Z

Talchu: Created page with "The guide ends with the bug inserted into the BugZilla DB, but... (1) what happens NOW, after a bug is created? -- Does someone review it and assign it, or should the reporter..."

The guide ends with the bug inserted into the BugZilla DB, but... (1) what happens NOW, after a bug is created? -- Does someone review it and assign it, or should the reporter notify a mailing list, next to promote it? Do BugZilla Admins review the bugs? (2) What happens if the reporter feels no one read or did anything with his bug report? (it happened to me a few times). I'd recommend extend the above mentioned paragraph with this info, and overview the process earlier within the Wiki page. I'll edit the wiki page, according to info I'll receive. I've sent this question to the DEV, too.
--[[User:Talchu|Talchu]] ([[User talk:Talchu|talk]]) 19:02, 29 March 2014 (UTC)

Documentation/Building Guide/Building on MacOSX

2013-10-02T22:47:45Z

Talchu: /* Install the new Build */

{{Documentation/Building Guide TOC
|ShowNextPage=none
|ShowPrevPage=none
}}

{{DISPLAYTITLE:Building on Mac OS X}}
[[Category:MacOSX]]

__TOC__

= Overview =
This document explains how to build the Apache OpenOffice source code on Mac OS X systems.
{{Template:Documentation/Note|<code>$SRC_ROOT</code> will denote the directory in which the source code of Apache OpenOffice is stored.}}
{{Template:Documentation/Tip|You are advised to check the release notes for the release you are building to inform yourself about changes since previous releases.}}

= Requirements =

To build the office on Mac OS X several requirements/prerequisites have to be fulfilled.

== Mandatory Requirements ==
* '''Mac OS X''' version 10.4 (aka Tiger) or later (if using 10.5 aka Leopard, have a look at [[User:Dyrcona/LeopardBuild#flex]]
* '''Mac 10.4 SDK'''
* '''XCode''' version 2.4.1 or any XCode 3. If you want to use a newer version than the one that is shipped with your Mac OS X installation media, you need to register at the [https://connect.apple.com/ Apple Developer Connection] site (free of charge) to be able to [http://developer.apple.com/technology/xcode.html download it]. On Mac OS X 10.6 (Snow Leopard), make sure to install the optional 10.4 SDK with XCode.
* '''dmake''', the build environment depends currently on a special patched version of dmake that you can download and build on demand during configure and bootstrap. Or you can provide a prebuilt version and can specify it during configure.
* '''epm''', the build environment depends currently on a special patched version of epm (easy package manager) that you can download and build on demand during configure and bootstrap. Or you can provide a prebuilt version and can specify it during configure.

{{Template:Documentation/Note|XCode 3 and SDK 10.4 is currently required for building trunk or the releases. Work on supporting XCode>=4 is ongoing.}}

== Optional Requirements ==

=== Prebuilt unowinreg.dll ===

This library is Windows only but will be packed in the Apache OpenOffice SDK to ensure that it is available on all platforms. The library provides some glue code to setup a working UNO environment for UNO client applications connecting to an office and doing some remote automation via API. The library should be stored in ''main/external/unowinreg''. Only necessary for building the SDK.

The library can be downloaded under
* http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll

=== Prebuilt Mozilla archives (based on seamonkey1.1.13) ===

To enable macros/macro security (disabled by default for security reasons), you'll have to put the prebuilt archives of mozilla binaries in the ''main/moz/zipped'' directory.

Note: archives are Intel only for now.

'''Archives to be downloaded''' :

* http://tools.openoffice.org/moz_prebuild/OOo3.2/MACOSXGCCIinc.zip
* http://tools.openoffice.org/moz_prebuild/OOo3.2/MACOSXGCCIlib.zip
* http://tools.openoffice.org/moz_prebuild/OOo3.2/MACOSXGCCIruntime.zip

or from

* http://eric.bachard.free.fr/mac/moz/seamonkey_Intel/MACOSXGCCIinc.zip
* http://eric.bachard.free.fr/mac/moz/seamonkey_Intel/MACOSXGCCIlib.zip
* http://eric.bachard.free.fr/mac/moz/seamonkey_Intel/MACOSXGCCIruntime.zip

== Recommended tools ==

* '''ccache'''
If you intend to build Apache OpenOffice several times, you probably can benefit of ccache since it will speed up your future builds. The first time you make a build with ccache you won't notice it, but the next time the build will go up to five times faster.

You can install it using '''[http://www.finkproject.org/ Fink]'''. It is simply named "ccache". For '''[http://www.macports.org/ MacPorts]''' users the package is called "ccache".

If you don't use fink, you can download and build it yourself using the source provided at http://ccache.samba.org/

There are two ways to enable ccache - one is to set environment variables, the other way is to use symlinks.

Using environment variables:
export CC="ccache gcc"
export CXX="ccache g++"

Using the symlink approach:
# create a directory for the links
mkdir ~/bin
# create the symlinks pointing to ccache with the name of the compiler
ln -s /path/to/ccache ~/bin/gcc
ln -s /path/to/ccache ~/bin/g++
ln -s /path/to/ccache ~/bin/cc
ln -s /path/to/ccache ~/bin/c++
# no all you need to enable ccache is to prepend ~/bin to your PATH
$ export PATH=~/bin:$PATH

for both methody, you can add the "export ..." lines to your ~/.profile - that way you don't need to manually set it when building. You can still temporarily disable ccache (export CCACHE_DISABLE=1) in case you don't want to use it.

Since OOo is rather huge, you should increase the cache-size to 1 GB or more
ccache -M 1G

* '''subversion''' version '''1.5.4 or later'''
Since OOo's source code is managed using Subversion currently, you also need the svn client to checkout sources (otherwise you would be bount to source-tarballs that aren't generated that frequently). You can either compile yourself or use the subversion universal binaries from the [http://subversion.tigris.org subversion project] Version 1.5.4 or later is required because of important fixes related to the merge-feature.

== Get the source and prepare to build it ==

=== Get the source from SVN ===

You need about 4.7 GB for a checkout from the svn repository. Building the source requires another 5GB. 

* '''check out the latest source from svn'''

svn co https://svn.apache.org/repos/asf/openoffice/trunk aoo

=== One-Time preparation and scripts ===

Apache OpenOffice build environment is configured using the open-source configuration-management package 'autoconf'. So you can do your beloved './configure' command, is now done in the '''main''' source directory.

To save the configure parameters and use them with different milestones it is useful to create your own build script to configure the environment and to trigger the build.

The directory structure when you have checked out the sources from svn looks like:

aoo/
aoo/main
aoo/extras
aoo/test
aoo/ext_libraries
aoo/ext_sources

Move into '''main''' and configure a minimal environment to build your first version of Apache OpenOffice:

cd main

Run the autoconf command to prepare a new configure based on the latest changes in configure.in

autoconf

Run configure

./configure --without-stlport --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 --with-epm-url=http://www.msweet.org/files/project2/epm-3.7-source.tar.gz

This commands prepares a minimal environment to build the office without any category-b enabled external libraries. A pure Apache license compatible version. See also the configure switches ''--with-dmake-path'' and ''--with-epm'' to specify prebuilt versions of dmake or epm.

Finally you should run bootstrap to trigger further preparations and to create platform specific shell script to setup a working build environment. On Mac OS x for example '''MacOSXX86Env.Set.sh''' on a Intel based system.

=== Build environment with enabled category-b dependencies ===

To prepare a build environment that provides more features and make use of further external libraries which are under copyleft but viral licenses you have to explicitly enable this '''category-b''' components.

./configure --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 \
--with-epm-url=http://www.msweet.org/files/project2/epm-3.7-source.tar.gz \
--disable-build-mozilla \
--without-stlport \
--enable-verbose \
'''--enable-category-b'''\
--enable-wiki-publisher

===Example build script to simplify user specific configurations===
As mentioned before to save the configure parameters and use them with different versions it is useful to create your own build script to configure the environment.

Create 'build.sh' (to be written) :

<pre>
#! /bin/bash

echo "### checking for unowinreg.dll ... "
if [ ! -e ./external/unowinreg/unowinreg.dll ]; then
wget -O external/unowinreg/unowinreg.dll http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll
else
echo " unowinreg.dll found"
fi

echo "### checking for moz prebuild libs ... "
if [ ! -e ./moz/zipped/MACOSXGCCIinc.zip ]; then
wget -O ./moz/zipped/MACOSXGCCIinc.zip http://www.openoffice.org/tools/moz_prebuild/OOo3.2/MACOSXGCCIinc.zip
wget -O ./moz/zipped/MACOSXGCCIlib.zip http://www.openoffice.org/tools/moz_prebuild/OOo3.2/MACOSXGCCIlib.zip
wget -O ./moz/zipped/MACOSXGCCIruntime.zip http://www.openoffice.org/tools/moz_prebuild/OOo3.2/MACOSXGCCIruntime.zip
else
echo " moz prebuild libs found"
fi

if [ ! -e ./configure ]; then
echo "### autoconf ..."
autoconf
else
echo "### autoconf ..."
rm ./configure
autoconf
fi

echo "### Configure"
./configure --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 --with-epm-url=http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz

#./configure --with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b %Y)") - Rev. $(echo $(svn info) | sed -e 's/^.*Last Changed Rev: //g' -e 's/ .*//g')" \
--disable-build-mozilla \
--enable-verbose --enable- category-b --enable-minimizer --enable-presenter-console --enable-wiki-publisher \
--with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 \
--with-epm-url=http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz

./bootstrap
</pre>

Put this script into ~/bin and make sure it is executable :

chmod ug+x ~/bin/build.sh

We used the bash shell in all example, since to our belief users of the C-shell are smart enough to figure out the differences anyway. If you want to dig deeper into the build process, please have a look at the description [http://tools.openoffice.org/build_env.html OpenOffice.org's Build Environment].

== Doing the build ==

After running configure and bootstrap we should have a working build environment and all necessary scripts should have been created. From now on you can use '''MacOSXX86Env.Set.sh''' to prepare a new shell with a working build environment.

=== On Mac Intel ===

source MacOSXX86Env.Set.sh
cd instsetoo_native
build --all

or

build --all -P4

=== On PowerPC ===

source MacOSXPPCEnv.Set.sh
cd instsetoo_native
build --all

or

build --all -P2

=== Comments on above ===

'''TODO TODO TODO ....'''

if you run into trouble with --dlv_switch (see: {{Bug|77360}})

The main purpose of the '''bootstrap''' script is to build (if necessary) the dmake utility used. Dmake once was a unix make-clone made by wticorp but got incorporated into OpenOffice since it was orphaned. For more information about dmake, it's history and manpage have a look here: http://tools.openoffice.org/dmake/index.html

Sourcing MacOSXPPCEnv.Set.sh is very important not only for building but also for '''running''' svdem later on. Here all the Environment-Variables for the Build will be set up. For a detailed description see [[Environment_Variables]]. Please note that on Intel machines, 'MacOSXPPCEnv.Set.sh' should be substituted with 'MacOSXX86Env.Set.sh'.

This Build process takes on my box (Dual 1.8 GHz G5, 1.5GB RAM) roughly 10 hours, and 3 to 6 hours on Mac Intel (3:30h on a 2GHz DualCore INTEL iMac). Be patient.

If you want to see how the progress on that build is you can use two '''build''' options to get a comfortable view:

build ... <see above> ... --html --html_path /Users/$USER/Sites

where $USER is your user name. Then you can load in Firefox (not Safari!) the HTML file '''unxmacxi.pro.build.html''' via the in Mac OS X included Apache web server or diretctly form the directory ''/Users/$USER/Sites/''. This file is automatically being updated and is showing the status of the build and also the time needed since the build started.

If you build on Snow Leopard (aka Mac OS X 10.6): Set DYLD_INSERT_LIBRARIES to point to the correct libsqlite3.dylib:
<pre>
DYLD_INSERT_LIBRARIES=/usr/lib/libsqlite3.dylib
</pre>

== '''Installing, preparing and running OpenOffice.org''' ==

===''' Find the Bundle''' ===

Once the build completed, the final product ( en-US version ) is named : OOo_3.0.0_*_MacOSXIntel_install.dmg ( for version 3.0beta e.g.)

And is located in instsetoo_native/unxmacxi.pro/OpenOffice/dmg/install/en-US directory ( replace en-US with your locale )

[[Image:Bundle_Location3.0beta.jpg]]

=== '''Install the new Build''' ===

* double-click on the *.dmg icon
* drag the OpenOffice icon into a folder of your choice

=== '''Run the new Build''' ===

* double click the application icon in that folder

=== '''Screenshots''' ===

Now you can start to work with this [[Aqua_Screenshots | amazing productivity suite]].

== '''Contribute by finding, isolating, debugging or solving issues''' ==

=== '''Isolate a problem''' ===

==== '''Reduce a problem''' ====

* make a problem reproducable
* reduce it to a test case that is as small and simple as possible
* if a problem is specific to a document then please attach it to the issue. A mininal excerpt of the document that still shows the problem is even better.
* a screenshot of is a good idea if it clearly shows the problem

==== '''Using application switches''' ====

Application switches are often valuable for isolating a problem. Most of OpenOffice.org's options can be found its Tools->Options menu.
 
Some switches are so special that there is no user interface to change them. They are only useful for debugging and isolating a problem, but they are very valuable a that. So a developer might suggest to isolate a problem by setting an environment variable before running the application. E.g. for isolating problems with the menubar a developer might suggest to set the environment variable [[AQUA_NATIVE_MENUS]] to false. This is done by typing these commands into a terminal:
* cd <INSTALL_DIR>/OpenOffice.org/Contents/MacOS
* export AQUA_NATIVE_MENUS=false
* ./soffice.bin

==== '''Provide a call stack for crash problems''' ====

Please note that bugs involving crashes should provide a description of how to reproduce the problem and a callstack.
There are several ways to provide the callstack:
* the preferred method is to use OOo"s builtin [[CrashReporting|crash reporting tool]]
* developers may provide a [[Providing_a_gdb_backtrace | gdb backtrace]] of the problem
* if the above two methods don"t work then please attach a file with the details provided by the AppleCrashReporter

=== '''Check against known issues''' ===

Check the list of [http://www.openoffice.org/issues/buglist.cgi?issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=&chfieldvalue=&short_desc=&short_desc_type=fulltext&long_desc=&long_desc_type=fulltext&issue_file_loc=&issue_file_loc_type=fulltext&status_whiteboard=&status_whiteboard_type=fulltext&keywords=aqua&keywords_type=anytokens&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time&Submit+query=Submit+query open issues]

=== '''Report a new issue''' ===

Report [http://qa.openoffice.org/issue_handling/pre_submission.html new issues] after you have [[AquaBuild#Isolate_a_problem | isolated the problem]]

=== '''Debug a problem''' ===

Debugging problems is often easier in an development environment:
<ul>
<li>With XCode: [[MacOSX_Debug_OpenOffice.org_using_XCode]]</li>
<li>With Xemacs: [http://www.mikesicotte.com/2007/02/21/debugging-ooo-with-xemacs-and-gdb Michael Sicotte's blog entry]</li>
</ul>

Please note that XCode still has some problems with the executable named soffice.bin (because of the dot in the name). The issue has been reported to xcode-users list.

== '''Current Work in progress (Aqua specific work only)''' ==

With OOO300 the Aqua port became a mainstream port, so most Aqua issues are handled in regular GSL-Layer childworkspaces instead of dedicated Aqua CWSses. Other CWSses that are purely Aqua specific are being tracked below:

* '''{{CWS|ogltrans4mac|DEV300}}''' : Implement the 3D (OpenGL) transitions in Impress ( see : [[Mac_OS_X_Porting_-_OpenGL_transitions| OpenGL transitions on Mac OS X ]] )

==='''Child WorkSpaces in development''' ===

* '''{{CWS|appleremote03|DEV300}}''' : use the contextual menu in presentation mode with Impress. preliminary step

* '''{{CWS|hotmac|OOO300}}''' : fix memory deallocation problems in exit()

* '''{{CWS|macosxscanner01|DEV300}}''' (planned)

All patches that developers have that need testing or peer review should be added here.

==='''Child WorkSpaces in testing (closed for development)''' ===

*'''{{CWS|macmiscfixes}}''' : misc fixes for mac

*'''{{CWS|maccrashrep}}''' : support crash reporting for OSX builds

*'''{{CWS|quicklookplugin01}}''' : a plugin for the QuickLook system available in MacOSX from versions 10.5 onwards

==='''Child WorkSpaces waiting for integration''' ===

* '''{{CWS|appleremote02|DEV300}}''' : improve the Apple Remote use with Impress (use MEDIA_COMMAND stuff, improve code robustness, and portability )

==='''Child Workspaces integrated into OpenOffice's trunk''' ===

A historical overview of [[Aqua_Integrated_CWS | old Aqua specific ChildWorkspaces]].

== '''Known build issues '''==
*'''Tiger''': no known issues
*'''Leopard''': no known issues
*'''Snow Leopard''': no known issues
*'''Lion''': no known issues
*'''Mountain Lion''': no known issues

<div align="left" style="color:grey; font-size:12px">[[AquaBuild/Some Background | '''Some Background (what is a CWS, EIS) (click me to know more) ''']]</div>

== '''External links''' ==
* [https://issues.apache.org/ooo Apache OpenOffice Issuezilla] : a database of bugs, changes and enhancements
* There are [[MacOSXPortMeetings | regular meetings]] on IRC (archives are [[Previous_Mac_Meeting_logs | available]]).
* Apache OpenOffice has a complicated code base. [[Source_code_directories | Here]] is an overview.
* the official Apache OpenOffice blog is at [https://blogs.apache.org/OOo/]
* [http://www.cocoadev.com Cocoadev] provides great resources to get up to speed in Cocoa development
* Pierre Chatelier's excellent [http://ktd.club.fr/programmation/objective-c.php Objective C for C++ developers] is available in both english and french versions
* Details about OSX's [http://developer.apple.com/cocoa Cocoa API] are available in the XCode documentation

[[Category:Aqua]]
[[Category:Build_System]]

Documentation/Building Guide/Building on MacOSX

2013-10-02T22:47:13Z

Talchu: /* Install the new Build */

{{Documentation/Building Guide TOC
|ShowNextPage=none
|ShowPrevPage=none
}}

{{DISPLAYTITLE:Building on Mac OS X}}
[[Category:MacOSX]]

__TOC__

= Overview =
This document explains how to build the Apache OpenOffice source code on Mac OS X systems.
{{Template:Documentation/Note|<code>$SRC_ROOT</code> will denote the directory in which the source code of Apache OpenOffice is stored.}}
{{Template:Documentation/Tip|You are advised to check the release notes for the release you are building to inform yourself about changes since previous releases.}}

= Requirements =

To build the office on Mac OS X several requirements/prerequisites have to be fulfilled.

== Mandatory Requirements ==
* '''Mac OS X''' version 10.4 (aka Tiger) or later (if using 10.5 aka Leopard, have a look at [[User:Dyrcona/LeopardBuild#flex]]
* '''Mac 10.4 SDK'''
* '''XCode''' version 2.4.1 or any XCode 3. If you want to use a newer version than the one that is shipped with your Mac OS X installation media, you need to register at the [https://connect.apple.com/ Apple Developer Connection] site (free of charge) to be able to [http://developer.apple.com/technology/xcode.html download it]. On Mac OS X 10.6 (Snow Leopard), make sure to install the optional 10.4 SDK with XCode.
* '''dmake''', the build environment depends currently on a special patched version of dmake that you can download and build on demand during configure and bootstrap. Or you can provide a prebuilt version and can specify it during configure.
* '''epm''', the build environment depends currently on a special patched version of epm (easy package manager) that you can download and build on demand during configure and bootstrap. Or you can provide a prebuilt version and can specify it during configure.

{{Template:Documentation/Note|XCode 3 and SDK 10.4 is currently required for building trunk or the releases. Work on supporting XCode>=4 is ongoing.}}

== Optional Requirements ==

=== Prebuilt unowinreg.dll ===

This library is Windows only but will be packed in the Apache OpenOffice SDK to ensure that it is available on all platforms. The library provides some glue code to setup a working UNO environment for UNO client applications connecting to an office and doing some remote automation via API. The library should be stored in ''main/external/unowinreg''. Only necessary for building the SDK.

The library can be downloaded under
* http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll

=== Prebuilt Mozilla archives (based on seamonkey1.1.13) ===

To enable macros/macro security (disabled by default for security reasons), you'll have to put the prebuilt archives of mozilla binaries in the ''main/moz/zipped'' directory.

Note: archives are Intel only for now.

'''Archives to be downloaded''' :

* http://tools.openoffice.org/moz_prebuild/OOo3.2/MACOSXGCCIinc.zip
* http://tools.openoffice.org/moz_prebuild/OOo3.2/MACOSXGCCIlib.zip
* http://tools.openoffice.org/moz_prebuild/OOo3.2/MACOSXGCCIruntime.zip

or from

* http://eric.bachard.free.fr/mac/moz/seamonkey_Intel/MACOSXGCCIinc.zip
* http://eric.bachard.free.fr/mac/moz/seamonkey_Intel/MACOSXGCCIlib.zip
* http://eric.bachard.free.fr/mac/moz/seamonkey_Intel/MACOSXGCCIruntime.zip

== Recommended tools ==

* '''ccache'''
If you intend to build Apache OpenOffice several times, you probably can benefit of ccache since it will speed up your future builds. The first time you make a build with ccache you won't notice it, but the next time the build will go up to five times faster.

You can install it using '''[http://www.finkproject.org/ Fink]'''. It is simply named "ccache". For '''[http://www.macports.org/ MacPorts]''' users the package is called "ccache".

If you don't use fink, you can download and build it yourself using the source provided at http://ccache.samba.org/

There are two ways to enable ccache - one is to set environment variables, the other way is to use symlinks.

Using environment variables:
export CC="ccache gcc"
export CXX="ccache g++"

Using the symlink approach:
# create a directory for the links
mkdir ~/bin
# create the symlinks pointing to ccache with the name of the compiler
ln -s /path/to/ccache ~/bin/gcc
ln -s /path/to/ccache ~/bin/g++
ln -s /path/to/ccache ~/bin/cc
ln -s /path/to/ccache ~/bin/c++
# no all you need to enable ccache is to prepend ~/bin to your PATH
$ export PATH=~/bin:$PATH

for both methody, you can add the "export ..." lines to your ~/.profile - that way you don't need to manually set it when building. You can still temporarily disable ccache (export CCACHE_DISABLE=1) in case you don't want to use it.

Since OOo is rather huge, you should increase the cache-size to 1 GB or more
ccache -M 1G

* '''subversion''' version '''1.5.4 or later'''
Since OOo's source code is managed using Subversion currently, you also need the svn client to checkout sources (otherwise you would be bount to source-tarballs that aren't generated that frequently). You can either compile yourself or use the subversion universal binaries from the [http://subversion.tigris.org subversion project] Version 1.5.4 or later is required because of important fixes related to the merge-feature.

== Get the source and prepare to build it ==

=== Get the source from SVN ===

You need about 4.7 GB for a checkout from the svn repository. Building the source requires another 5GB. 

* '''check out the latest source from svn'''

svn co https://svn.apache.org/repos/asf/openoffice/trunk aoo

=== One-Time preparation and scripts ===

Apache OpenOffice build environment is configured using the open-source configuration-management package 'autoconf'. So you can do your beloved './configure' command, is now done in the '''main''' source directory.

To save the configure parameters and use them with different milestones it is useful to create your own build script to configure the environment and to trigger the build.

The directory structure when you have checked out the sources from svn looks like:

aoo/
aoo/main
aoo/extras
aoo/test
aoo/ext_libraries
aoo/ext_sources

Move into '''main''' and configure a minimal environment to build your first version of Apache OpenOffice:

cd main

Run the autoconf command to prepare a new configure based on the latest changes in configure.in

autoconf

Run configure

./configure --without-stlport --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 --with-epm-url=http://www.msweet.org/files/project2/epm-3.7-source.tar.gz

This commands prepares a minimal environment to build the office without any category-b enabled external libraries. A pure Apache license compatible version. See also the configure switches ''--with-dmake-path'' and ''--with-epm'' to specify prebuilt versions of dmake or epm.

Finally you should run bootstrap to trigger further preparations and to create platform specific shell script to setup a working build environment. On Mac OS x for example '''MacOSXX86Env.Set.sh''' on a Intel based system.

=== Build environment with enabled category-b dependencies ===

To prepare a build environment that provides more features and make use of further external libraries which are under copyleft but viral licenses you have to explicitly enable this '''category-b''' components.

./configure --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 \
--with-epm-url=http://www.msweet.org/files/project2/epm-3.7-source.tar.gz \
--disable-build-mozilla \
--without-stlport \
--enable-verbose \
'''--enable-category-b'''\
--enable-wiki-publisher

===Example build script to simplify user specific configurations===
As mentioned before to save the configure parameters and use them with different versions it is useful to create your own build script to configure the environment.

Create 'build.sh' (to be written) :

<pre>
#! /bin/bash

echo "### checking for unowinreg.dll ... "
if [ ! -e ./external/unowinreg/unowinreg.dll ]; then
wget -O external/unowinreg/unowinreg.dll http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll
else
echo " unowinreg.dll found"
fi

echo "### checking for moz prebuild libs ... "
if [ ! -e ./moz/zipped/MACOSXGCCIinc.zip ]; then
wget -O ./moz/zipped/MACOSXGCCIinc.zip http://www.openoffice.org/tools/moz_prebuild/OOo3.2/MACOSXGCCIinc.zip
wget -O ./moz/zipped/MACOSXGCCIlib.zip http://www.openoffice.org/tools/moz_prebuild/OOo3.2/MACOSXGCCIlib.zip
wget -O ./moz/zipped/MACOSXGCCIruntime.zip http://www.openoffice.org/tools/moz_prebuild/OOo3.2/MACOSXGCCIruntime.zip
else
echo " moz prebuild libs found"
fi

if [ ! -e ./configure ]; then
echo "### autoconf ..."
autoconf
else
echo "### autoconf ..."
rm ./configure
autoconf
fi

echo "### Configure"
./configure --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 --with-epm-url=http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz

#./configure --with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b %Y)") - Rev. $(echo $(svn info) | sed -e 's/^.*Last Changed Rev: //g' -e 's/ .*//g')" \
--disable-build-mozilla \
--enable-verbose --enable- category-b --enable-minimizer --enable-presenter-console --enable-wiki-publisher \
--with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 \
--with-epm-url=http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz

./bootstrap
</pre>

Put this script into ~/bin and make sure it is executable :

chmod ug+x ~/bin/build.sh

We used the bash shell in all example, since to our belief users of the C-shell are smart enough to figure out the differences anyway. If you want to dig deeper into the build process, please have a look at the description [http://tools.openoffice.org/build_env.html OpenOffice.org's Build Environment].

== Doing the build ==

After running configure and bootstrap we should have a working build environment and all necessary scripts should have been created. From now on you can use '''MacOSXX86Env.Set.sh''' to prepare a new shell with a working build environment.

=== On Mac Intel ===

source MacOSXX86Env.Set.sh
cd instsetoo_native
build --all

or

build --all -P4

=== On PowerPC ===

source MacOSXPPCEnv.Set.sh
cd instsetoo_native
build --all

or

build --all -P2

=== Comments on above ===

'''TODO TODO TODO ....'''

if you run into trouble with --dlv_switch (see: {{Bug|77360}})

The main purpose of the '''bootstrap''' script is to build (if necessary) the dmake utility used. Dmake once was a unix make-clone made by wticorp but got incorporated into OpenOffice since it was orphaned. For more information about dmake, it's history and manpage have a look here: http://tools.openoffice.org/dmake/index.html

Sourcing MacOSXPPCEnv.Set.sh is very important not only for building but also for '''running''' svdem later on. Here all the Environment-Variables for the Build will be set up. For a detailed description see [[Environment_Variables]]. Please note that on Intel machines, 'MacOSXPPCEnv.Set.sh' should be substituted with 'MacOSXX86Env.Set.sh'.

This Build process takes on my box (Dual 1.8 GHz G5, 1.5GB RAM) roughly 10 hours, and 3 to 6 hours on Mac Intel (3:30h on a 2GHz DualCore INTEL iMac). Be patient.

If you want to see how the progress on that build is you can use two '''build''' options to get a comfortable view:

build ... <see above> ... --html --html_path /Users/$USER/Sites

where $USER is your user name. Then you can load in Firefox (not Safari!) the HTML file '''unxmacxi.pro.build.html''' via the in Mac OS X included Apache web server or diretctly form the directory ''/Users/$USER/Sites/''. This file is automatically being updated and is showing the status of the build and also the time needed since the build started.

If you build on Snow Leopard (aka Mac OS X 10.6): Set DYLD_INSERT_LIBRARIES to point to the correct libsqlite3.dylib:
<pre>
DYLD_INSERT_LIBRARIES=/usr/lib/libsqlite3.dylib
</pre>

== '''Installing, preparing and running OpenOffice.org''' ==

===''' Find the Bundle''' ===

Once the build completed, the final product ( en-US version ) is named : OOo_3.0.0_*_MacOSXIntel_install.dmg ( for version 3.0beta e.g.)

And is located in instsetoo_native/unxmacxi.pro/OpenOffice/dmg/install/en-US directory ( replace en-US with your locale )

[[Image:Bundle_Location3.0beta.jpg]]

=== '''Install the new Build''' ===

* double click on the *.dmg icon
* drag the OpenOffice icon into a folder of your choice

=== '''Run the new Build''' ===

* double click the application icon in that folder

=== '''Screenshots''' ===

Now you can start to work with this [[Aqua_Screenshots | amazing productivity suite]].

== '''Contribute by finding, isolating, debugging or solving issues''' ==

=== '''Isolate a problem''' ===

==== '''Reduce a problem''' ====

* make a problem reproducable
* reduce it to a test case that is as small and simple as possible
* if a problem is specific to a document then please attach it to the issue. A mininal excerpt of the document that still shows the problem is even better.
* a screenshot of is a good idea if it clearly shows the problem

==== '''Using application switches''' ====

Application switches are often valuable for isolating a problem. Most of OpenOffice.org's options can be found its Tools->Options menu.
 
Some switches are so special that there is no user interface to change them. They are only useful for debugging and isolating a problem, but they are very valuable a that. So a developer might suggest to isolate a problem by setting an environment variable before running the application. E.g. for isolating problems with the menubar a developer might suggest to set the environment variable [[AQUA_NATIVE_MENUS]] to false. This is done by typing these commands into a terminal:
* cd <INSTALL_DIR>/OpenOffice.org/Contents/MacOS
* export AQUA_NATIVE_MENUS=false
* ./soffice.bin

==== '''Provide a call stack for crash problems''' ====

Please note that bugs involving crashes should provide a description of how to reproduce the problem and a callstack.
There are several ways to provide the callstack:
* the preferred method is to use OOo"s builtin [[CrashReporting|crash reporting tool]]
* developers may provide a [[Providing_a_gdb_backtrace | gdb backtrace]] of the problem
* if the above two methods don"t work then please attach a file with the details provided by the AppleCrashReporter

=== '''Check against known issues''' ===

Check the list of [http://www.openoffice.org/issues/buglist.cgi?issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=&chfieldvalue=&short_desc=&short_desc_type=fulltext&long_desc=&long_desc_type=fulltext&issue_file_loc=&issue_file_loc_type=fulltext&status_whiteboard=&status_whiteboard_type=fulltext&keywords=aqua&keywords_type=anytokens&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time&Submit+query=Submit+query open issues]

=== '''Report a new issue''' ===

Report [http://qa.openoffice.org/issue_handling/pre_submission.html new issues] after you have [[AquaBuild#Isolate_a_problem | isolated the problem]]

=== '''Debug a problem''' ===

Debugging problems is often easier in an development environment:
<ul>
<li>With XCode: [[MacOSX_Debug_OpenOffice.org_using_XCode]]</li>
<li>With Xemacs: [http://www.mikesicotte.com/2007/02/21/debugging-ooo-with-xemacs-and-gdb Michael Sicotte's blog entry]</li>
</ul>

Please note that XCode still has some problems with the executable named soffice.bin (because of the dot in the name). The issue has been reported to xcode-users list.

== '''Current Work in progress (Aqua specific work only)''' ==

With OOO300 the Aqua port became a mainstream port, so most Aqua issues are handled in regular GSL-Layer childworkspaces instead of dedicated Aqua CWSses. Other CWSses that are purely Aqua specific are being tracked below:

* '''{{CWS|ogltrans4mac|DEV300}}''' : Implement the 3D (OpenGL) transitions in Impress ( see : [[Mac_OS_X_Porting_-_OpenGL_transitions| OpenGL transitions on Mac OS X ]] )

==='''Child WorkSpaces in development''' ===

* '''{{CWS|appleremote03|DEV300}}''' : use the contextual menu in presentation mode with Impress. preliminary step

* '''{{CWS|hotmac|OOO300}}''' : fix memory deallocation problems in exit()

* '''{{CWS|macosxscanner01|DEV300}}''' (planned)

All patches that developers have that need testing or peer review should be added here.

==='''Child WorkSpaces in testing (closed for development)''' ===

*'''{{CWS|macmiscfixes}}''' : misc fixes for mac

*'''{{CWS|maccrashrep}}''' : support crash reporting for OSX builds

*'''{{CWS|quicklookplugin01}}''' : a plugin for the QuickLook system available in MacOSX from versions 10.5 onwards

==='''Child WorkSpaces waiting for integration''' ===

* '''{{CWS|appleremote02|DEV300}}''' : improve the Apple Remote use with Impress (use MEDIA_COMMAND stuff, improve code robustness, and portability )

==='''Child Workspaces integrated into OpenOffice's trunk''' ===

A historical overview of [[Aqua_Integrated_CWS | old Aqua specific ChildWorkspaces]].

== '''Known build issues '''==
*'''Tiger''': no known issues
*'''Leopard''': no known issues
*'''Snow Leopard''': no known issues
*'''Lion''': no known issues
*'''Mountain Lion''': no known issues

<div align="left" style="color:grey; font-size:12px">[[AquaBuild/Some Background | '''Some Background (what is a CWS, EIS) (click me to know more) ''']]</div>

== '''External links''' ==
* [https://issues.apache.org/ooo Apache OpenOffice Issuezilla] : a database of bugs, changes and enhancements
* There are [[MacOSXPortMeetings | regular meetings]] on IRC (archives are [[Previous_Mac_Meeting_logs | available]]).
* Apache OpenOffice has a complicated code base. [[Source_code_directories | Here]] is an overview.
* the official Apache OpenOffice blog is at [https://blogs.apache.org/OOo/]
* [http://www.cocoadev.com Cocoadev] provides great resources to get up to speed in Cocoa development
* Pierre Chatelier's excellent [http://ktd.club.fr/programmation/objective-c.php Objective C for C++ developers] is available in both english and french versions
* Details about OSX's [http://developer.apple.com/cocoa Cocoa API] are available in the XCode documentation

[[Category:Aqua]]
[[Category:Build_System]]

Talk:Documentation/Building Guide/Building on MacOSX

2013-09-28T10:30:51Z

Talchu: /* Installing, preparing and running OpenOffice.org */

just added some quotes around the export CVSROOT= line

----

=== Installing, preparing and running OpenOffice.org ===

"And is located in instsetoo_native/unxmacxi.pro/OpenOffice/archive/install/en-US directory ( replace en-US with your locale )"

For me, it is located in instsetoo_native/unxmacxi.pro/OpenOffice/'''dmg'''/install/en-US. Not sure if this is unique to certain setups, or if it has changed in newer CVS revisions.

[[User:GlowingApple|GlowingApple]] 05:15, 27 January 2008 (CET)

You are right, the path has been modified recently, after dmgunarchive cws integration.

My idea is wait until DEV300 branch is created, before to update the AquaBuild page, because a lot of infos will change too.

Are you ok to wait a bit ?

[[User:Ericb|Ericb]] 09:07, 27 January 2008 (CET)

[[User:Talchu|Talchu]] 2013-09-28: It isn't clear where to state DYLD_INSERT_LIBRARIES=/usr/lib/libsqlite3.dylib

== Renaming Mozilla files ==

The table is bad IMHO in the article (runtime: MACOSXGCCIruntime.zip to MACOSXGCCPlib.zip) please correct it.

Thanks for the great job

[[User:Shooby|Shooby]] 16:30, 13 October 2008 (CET)

Documentation/Building Guide AOO

2013-09-28T09:00:16Z

Talchu: /* Frequently used options */

{{DISPLAYTITLE:Apache OpenOffice Building Guide}}

= Preface =
This guide will help you to build Apache OpenOffice from its source code. It details the prerequisites and explains how to download the source code, prepare and then run the build. [[Documentation/Building_Guide_AOO/Step_by_step|Step-by-step instructions]] for resolving the pre-requisites of individual platforms and building on them are available.

Here is the short version for the brave and impatient:
* Download the source: <code>svn co https://svn.apache.org/repos/asf/openoffice/trunk aoo</code>
* Configure: <code>cd main/ ; autoconf ; ./configure <some-switches> ; ./bootstrap</code>
* Build: <code>source <platform-dependend-name>.sh ; cd instsetoo_native ; build --all</code>
* Wait for an hour or more (The build can take up to 3 hours.)
* Install office
* Enjoy

The detailed description below gives a broader introduction into the build process and explains for the various steps.

==Status==
This document is loosely based on an older [[Documentation/Building Guide|version]]. I have tried to avoid duplication and to move anything that all platforms have in common to this page. Many details have been removed on purpose because they refer to older version of OpenOffice. However, there are still some things not explained in the necessary detail on this page:
* How to use mozilla and nss.
* How to use ccache

{{Documentation/SeeAlso|*[[How_to_build_Symphony%27s_source_code]] }}

= Getting help =
You can get help by searching this wiki or by asking questions on the [http://openoffice.apache.org/mailing-lists.html#development-mailing-list-public developers mailing list].

You can help us improve this guide by pointing out any errors (preferably after finding a solution).
Or don't be shy and edit (and improve) these pages yourself.

= Basics =

In order to build Apache OpenOffice you need a proper environment. This includes
* a command line interpreter, typically bourne shell compatible (sh or bash) inside a terminal. On Windows you will need to install Cygwin to provide it.
* C++ compiler and linker. The exact choice depends on the operating system.
* Perl interpreter and several modules.
* Many tools from the Unix world like make or sed.

See section [[#General_Build_Requirements | General Build Requirements]]
for an exact list of requirements.

= Getting the source =

The source code is available as SVN repository at https://svn.apache.org/repos/asf/openoffice

Check it out with

svn co https://svn.apache.org/repos/asf/openoffice/trunk aoo

More details about how to check out source code from SVN can be found [http://openoffice.apache.org/source.html here].

== Space Requirements ==

The checked out files take up somewhat over 5GB on disk (more than 150000 files in more than 7000 folders and the SVN overhead).

After building this becomes (on Windows7) almost 17GB (more than 406000 files in more than 23000 folders).

You can use git as well. There exists no guide for this, therefore ask on dev@openoffice.apache.org, if you want to use git.

= Organization of the source and output tree =

The source code has five top level directories:
;main/:contains most of the so called modules. Each module typically provides one or more libraries. The source code of the writer application for example can be found in main/sd/.
;test/:contains the new [[QA/test_automation_guide | automated testing framework]]
;ext_libraries/:is the new home of modules that build external libraries (libraries maintained outside of Apache OpenOffice and often outside Apache).
;ext_sources/:contains the tar balls (archives) of external libraries. They are included both for convenience and to make sure that specific versions remain available. Note that the source package of the Apache OpenOffice release does not contain any external tar balls.
;extras/:holds the localization data.

Most tools and scripts that are used for building are located below <code>main/solenv/</code>:
*dmake makefiles in <code>main/solenv/inc/</code>
*gmake makefiles in <code>main/solenv/gbuild/</code>
*executables and perl files in <code>main/solenv/bin/</code>
*perl modules in <code>main/bin/modules/</code>

Libraries and other output files that are shared between modules are stored in <code>main/solver/</code>.

=Building=

==Overview==

Building Apache OpenOffice consists of three steps:
;Configuring/bootstrapping:Detect platform, operating system, compiler, etc. and write the information into a shell script for later use. The developer can turn on or off certain features in this phase.
;Building:Compile the source code, transform other input files, apply localization.
;Packing:Create a set of files, the installation set, that can be installed on the respective operating system. This can be msi/cab files for windows, deb or rpm for Linux, dmg for Mac.

The configure step has to be carried out only once. Building and packing is necessary after every source code change. There are short cuts to avoid parts of these steps (when you know what you are doing.)

The building examples in this wiki document use only command line approaches to building. Depending on your expertise, it may be possible to use an IDE which allows specification of custom build scripts.

== General Build Requirements ==

The general requirements for all platforms are
{| class="prettytable"
|- valign="top"
! Requirement
! Description
! Configure switch
|- valign="top"
| Java JDK
| Java Implementation compatible with [http://java.sun.com/j2se/1.5/ JDK 1.5] or [http://java.sun.com/javase/6/ JDK 1.6]. [http://openjdk.java.net/ OpenJDK] is supported as well.

For Windows [http://www.oracle.com/technetwork/java/javase/downloads/index.html/ JDK 1.7] is recommended.
| --with-jdk-home=
|- valign="top"
| Perl
| Perl 5 - note: for Windows Perl will be installed as part of the cygwin environment.

Also required are the perl packages
Archive::Zip
LWP::UserAgent
XML::Parser
They can be installed from the shell with (you may have to run it with super user/administrator rights)
perl -MCPAN -e shell
If it is executed for the first time then CPAN will ask for configuration. Choose autoconfiguration.
Eventually the CPAN shell appeares accepts commands. Install missing modules with
install <module-name>
Find more details [http://wiki.services.openoffice.org/wiki/CPAN_install here].5
|- valign="top"
| CUPS
| cups headers. Provided by a cups-devel package or a libcups2-devel

note: not for Windows
|- valign="top"
| PAM
| PAM support. Provided by a pam-devel package or a libpam-dev

note: not for Windows
|- valign="top"
| Apache Ant
| [http://ant.apache.org/ Ant 1.9 or later] (see note)
| --with-ant-home=
|- valign="top"
| Archiver
| zip and unzip - note: for Windows zip and unzip will be installed as part of the cygwin environment.
|- valign="top"
| gperf
| [http://www.gnu.org/software/gperf/gperf.html gperf] tool - note: for Windows gperf will be installed as part of the cygwin environment.
|- valign="top"
| Mozilla
| Some Mozilla libraries are needed. Choose one of the following:
* Recommended: Get prebuild libraries from [http://tools.openoffice.org/moz_prebuild/680/ here].1
* Not recommended: Get the source from [http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.5/source/ here].2
|- valign="top"
| NSS3
| For Windows the Mozilla build tools4 are needed to build module nss. They can be obtained [http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/ here].
|-
|}

'''Notes:'''
# You have to configure with --disable-build-mozilla to enable the use of the prebuild libraries. Place LINUXGCCI{inc,lib,runtime}.zip into <tt>main/moz/zipped</tt>. The files can be reused if the packages were build following the instructions of the previous point. In the latter case they can be found in main/moz/unxlngi6.pro of a successful build.
# Copy the package into <tt>main/moz/download</tt>. The ./configure script will detect the source being present.
# The nss module will be introduced in DEV300m57 (DEV300m57 is the designation of a milestone during the former OpenOffice.org era which has been created in Sep. 2009). nss contains a subset of libraries from Mozilla (the moz module). They are supposed to be more current than those in the moz module. To prevent building nss and instead use the libraries from the moz module one can use the configure switch <tt>--disable-nss-module</tt>. '''This switch will be removed soon!'''
# Use the configure switch <tt>--with-mozilla-build</tt> to tell configure where the tools are installed. For example: <tt>--with-mozilla-build=c:/mozilla-build</tt>
# Please note that CPAN is not able to deal with usernames containing spaces. To work around this fact, when CPAN asks you to specify the CPAN build and cache directory, change the default suggestion to /cpan.
# Apache Ant: Assure a proper ant set-up by downloading and installing ant, in total, from the ant site linked above. If you are a Linux developer, your distro may not have ant setup correctly for building Apache OpenOffice.
# Use <tt>./configure --help</tt> to see all possible configuration options

See also the platform specific requirements for
*[[Documentation/Building_Guide_AOO/Building_on_Windows|Windows]]
*[[Documentation/Building_Guide_AOO/Building_on_Linux|Linux]]
*[[Documentation/Building_Guide_AOO/Building_on_MacOsX|MacOSX]]

==Configuration and bootstrapping==
This is typically done only once after the source code is checked out. Repeat this after changing your mind about options given to configure.

The call to
autoconf
creates the main/configure script from main/configure.in and some other input files.

The set of options/switches given to configure depends on the platform and your choice of features. A typical call starts like this
configure \
--with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 \
--with-epm-url=http://www.msweet.org/files/project2/epm-3.7-source.tar.gz \
It tells configure where to find the source code of external tools dmake and epm.

By default only source code under [http://www.apache.org/legal/3party.html#category-a category A] licenses is compiled and included. Besides the Apache License 2.0 this includes for example BSD and MIT/X11 license. If you want to enable features that rely on third party code under [http://www.apache.org/legal/3party.html#category-b category B] licenses (like MPL, CPL, EPL, etc) then add the option
--enable-category-b

For inclusion of externally hosted dictionary extensions add option
--enable-bundled-dictionaries
Note that dictionaries rely on a category B third party library (hunspell). Therefore <code>--enable-category-b</code> is a prerequisite for <code>--enable-bundled-dictionaries</code>. Dictionaries have a variety of licenses and are bundled without modification: they are not compiled.

The <code>--with-lang</code> option will introduce the build of additional language resources. This switch accepts one or more RFC 1766 language tags as arguments, unfortunately not all languages are supported. Check the <code>[http://svn.apache.org/viewvc/openoffice/trunk/main/solenv/inc/langlist.mk?view=markup solenv/inc/langlist.mk]</code> file for all the currently supported language tags. The environment variable WITH_LANG will then contain the language tags of the additional (en-US will always be build) languages. Example:
--with-lang="de fr"
enables the build of the localized German and French version.

You can run the rat scan while building with option
--with-rat-scan
[[Documentation/Building_Guide_AOO/Rat_Scan|Here]] you can find details.

Finish this step by running
./bootstrap
This will build dmake and epm, download missing source code tar balls of external libraries, and download missing external dictionary extensions.

==Building==
Start by including the environment variables prepared by configure into your current environment with
<tt>source <shell-script-name></tt>
where <shell-script-name> depends on your platform:
{| class="prettytable"
|-
!platform id
!<shell-script-name>
|-
| wntmsci12
| winenv.set.sh
|-
| unxlngi6
| LinuxX86Env.Set.sh
|-
| unxlngx6
| LinuxX86-64Env.Set.sh
|-
| unxmacxi
| MacOSXX86Env.Set.sh
|}
Look into main/set_soenv for more platforms. (search for lines <code>$OUTPATH = "<platform>";</code> and the nearby line <code>$outfile = "<shell-script-name>";</code>. Add the suffix <code>.sh</code> for the bash variant.

If you want to build the whole office and the install sets then
cd main/instsetoo_native
build --all
You may want to experiment with the -P options for multi process builds to reduce the build time.
build --all -P<m> -- -P<n>
tells build to use <code>m</code> processes (build up to <code>m</code> modules in parallel) and <code>n</code> threads for each module.

Building Apache OpenOffice uses a custom build command, build.pl, located in /main/solenv/bin.
You may it helpful to learn more about build options from the [http://www.openoffice.org/tools/tools/build.html Build Documentation]

==Partial Builds==

Building the whole office takes a lot of time. Therefore it may be preferable to build only parts after making changes to the source code.
There are two different types of partial builds:
;Compatible:Can be used only when the code changes do not change exported interfaces. Use with care and only when you know what you are doing.
;Incompatible:Use for code changes that modify exported C++ or IDL interfaces, that modify resources that are used by other modules, or when you are not sure.
:If you are a new developer, you should probably always assume your changes are "incompatible" and follow the instructions for '''Incompatible Build'''.

===Make Systems Used by Apache OpenOffice===

For the following Build sections you should be aware that Apache OpenOffice uses two different '''make''' systems to build its modules.
*The older one is based on dmake
*The other and newer one is based on GNU make. This system is often referred to as gbuild.
When a module contains, among others, a Makefile and a Module_<module>.mk file then it is a gbuild module.

===Compatible Build===

After changing code in module <module> which does not change any exported interfaces do
{|class="prettytable"
|-
!dmake
!gbuild
|-
|
cd <module>
build
deliver
|
cd <module>
make -sr
No explicit call to <code>deliver</code> is necessary for gbuild modules.
|}
to compile and deliver the resulting libraries to <code>main/solver/</code>. You may want to erase the output of a previous compilation:
{|class="prettytable"
|-
!dmake
!gbuild
|-
|
cd <module>
build --from <module> --prepare
or faster (but without the un-deliver)
cd <module>
rm -fr <platform>/
|
cd <module>
make clean
|}

===Incompatible Build===

Modifications that change exported interfaces require not only the module to be rebuild that contains the modified code. All depending modules (dependencies are defined in <code><module>/prj/build.lst</code>) have to be rebuild as well. This is best done from <code>main/instsetoo_native/</code>:
<tt>cd main/instsetoo_native/</tt>
<tt>build --from <incompatible-module> --prepare</tt>
<tt>build --from <incompatible-module></tt>

The second line removes the output of all modules that have to be recompiled. The drawback of this command is that the output of modules which are build via gbuild are not removed. Thus, the following additional command performed after the second one will do the trick:
build --from <incompatible-module> --job="make clean; make clean debug=t" --ignore

===Frequently used options===

In order to add debug information to libraries and executables, add the <code>debug</code> switch to any <code>build</code> or <code>make</code> command:
{|class="prettytable"
|-
!dmake
!gbuild
|-
|
cd <module>
build debug=t
|
cd <module>
make -sr debug=t
|}
Remember that for the gbuild system you have to use the debug flag also when cleaning a module (otherwise eg the wrong precompiled headers are deleted and are not rebuilt):
make clean debug=t

You can force make to rebuild dependency information by first deleting it with the depend option. It would be rebuilt automatically with the next build:
{|class="prettytable"
|-
!dmake
!gbuild
|-
|
cd <module>
build depend=t
build
|
cd <module>
make -sr depend=t
make -sr
|}

= [http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step Step-by-Step Building Guide for Different Platforms] =
[[Category:Documentation]][[Category:Development]][[Category:Porting]]

Documentation/Building Guide AOO

2013-09-28T08:56:10Z

Talchu: /* Frequently used options */

{{DISPLAYTITLE:Apache OpenOffice Building Guide}}

= Preface =
This guide will help you to build Apache OpenOffice from its source code. It details the prerequisites and explains how to download the source code, prepare and then run the build. [[Documentation/Building_Guide_AOO/Step_by_step|Step-by-step instructions]] for resolving the pre-requisites of individual platforms and building on them are available.

Here is the short version for the brave and impatient:
* Download the source: <code>svn co https://svn.apache.org/repos/asf/openoffice/trunk aoo</code>
* Configure: <code>cd main/ ; autoconf ; ./configure <some-switches> ; ./bootstrap</code>
* Build: <code>source <platform-dependend-name>.sh ; cd instsetoo_native ; build --all</code>
* Wait for an hour or more (The build can take up to 3 hours.)
* Install office
* Enjoy

The detailed description below gives a broader introduction into the build process and explains for the various steps.

==Status==
This document is loosely based on an older [[Documentation/Building Guide|version]]. I have tried to avoid duplication and to move anything that all platforms have in common to this page. Many details have been removed on purpose because they refer to older version of OpenOffice. However, there are still some things not explained in the necessary detail on this page:
* How to use mozilla and nss.
* How to use ccache

{{Documentation/SeeAlso|*[[How_to_build_Symphony%27s_source_code]] }}

= Getting help =
You can get help by searching this wiki or by asking questions on the [http://openoffice.apache.org/mailing-lists.html#development-mailing-list-public developers mailing list].

You can help us improve this guide by pointing out any errors (preferably after finding a solution).
Or don't be shy and edit (and improve) these pages yourself.

= Basics =

In order to build Apache OpenOffice you need a proper environment. This includes
* a command line interpreter, typically bourne shell compatible (sh or bash) inside a terminal. On Windows you will need to install Cygwin to provide it.
* C++ compiler and linker. The exact choice depends on the operating system.
* Perl interpreter and several modules.
* Many tools from the Unix world like make or sed.

See section [[#General_Build_Requirements | General Build Requirements]]
for an exact list of requirements.

= Getting the source =

The source code is available as SVN repository at https://svn.apache.org/repos/asf/openoffice

Check it out with

svn co https://svn.apache.org/repos/asf/openoffice/trunk aoo

More details about how to check out source code from SVN can be found [http://openoffice.apache.org/source.html here].

== Space Requirements ==

The checked out files take up somewhat over 5GB on disk (more than 150000 files in more than 7000 folders and the SVN overhead).

After building this becomes (on Windows7) almost 17GB (more than 406000 files in more than 23000 folders).

You can use git as well. There exists no guide for this, therefore ask on dev@openoffice.apache.org, if you want to use git.

= Organization of the source and output tree =

The source code has five top level directories:
;main/:contains most of the so called modules. Each module typically provides one or more libraries. The source code of the writer application for example can be found in main/sd/.
;test/:contains the new [[QA/test_automation_guide | automated testing framework]]
;ext_libraries/:is the new home of modules that build external libraries (libraries maintained outside of Apache OpenOffice and often outside Apache).
;ext_sources/:contains the tar balls (archives) of external libraries. They are included both for convenience and to make sure that specific versions remain available. Note that the source package of the Apache OpenOffice release does not contain any external tar balls.
;extras/:holds the localization data.

Most tools and scripts that are used for building are located below <code>main/solenv/</code>:
*dmake makefiles in <code>main/solenv/inc/</code>
*gmake makefiles in <code>main/solenv/gbuild/</code>
*executables and perl files in <code>main/solenv/bin/</code>
*perl modules in <code>main/bin/modules/</code>

Libraries and other output files that are shared between modules are stored in <code>main/solver/</code>.

=Building=

==Overview==

Building Apache OpenOffice consists of three steps:
;Configuring/bootstrapping:Detect platform, operating system, compiler, etc. and write the information into a shell script for later use. The developer can turn on or off certain features in this phase.
;Building:Compile the source code, transform other input files, apply localization.
;Packing:Create a set of files, the installation set, that can be installed on the respective operating system. This can be msi/cab files for windows, deb or rpm for Linux, dmg for Mac.

The configure step has to be carried out only once. Building and packing is necessary after every source code change. There are short cuts to avoid parts of these steps (when you know what you are doing.)

The building examples in this wiki document use only command line approaches to building. Depending on your expertise, it may be possible to use an IDE which allows specification of custom build scripts.

== General Build Requirements ==

The general requirements for all platforms are
{| class="prettytable"
|- valign="top"
! Requirement
! Description
! Configure switch
|- valign="top"
| Java JDK
| Java Implementation compatible with [http://java.sun.com/j2se/1.5/ JDK 1.5] or [http://java.sun.com/javase/6/ JDK 1.6]. [http://openjdk.java.net/ OpenJDK] is supported as well.

For Windows [http://www.oracle.com/technetwork/java/javase/downloads/index.html/ JDK 1.7] is recommended.
| --with-jdk-home=
|- valign="top"
| Perl
| Perl 5 - note: for Windows Perl will be installed as part of the cygwin environment.

Also required are the perl packages
Archive::Zip
LWP::UserAgent
XML::Parser
They can be installed from the shell with (you may have to run it with super user/administrator rights)
perl -MCPAN -e shell
If it is executed for the first time then CPAN will ask for configuration. Choose autoconfiguration.
Eventually the CPAN shell appeares accepts commands. Install missing modules with
install <module-name>
Find more details [http://wiki.services.openoffice.org/wiki/CPAN_install here].5
|- valign="top"
| CUPS
| cups headers. Provided by a cups-devel package or a libcups2-devel

note: not for Windows
|- valign="top"
| PAM
| PAM support. Provided by a pam-devel package or a libpam-dev

note: not for Windows
|- valign="top"
| Apache Ant
| [http://ant.apache.org/ Ant 1.9 or later] (see note)
| --with-ant-home=
|- valign="top"
| Archiver
| zip and unzip - note: for Windows zip and unzip will be installed as part of the cygwin environment.
|- valign="top"
| gperf
| [http://www.gnu.org/software/gperf/gperf.html gperf] tool - note: for Windows gperf will be installed as part of the cygwin environment.
|- valign="top"
| Mozilla
| Some Mozilla libraries are needed. Choose one of the following:
* Recommended: Get prebuild libraries from [http://tools.openoffice.org/moz_prebuild/680/ here].1
* Not recommended: Get the source from [http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.5/source/ here].2
|- valign="top"
| NSS3
| For Windows the Mozilla build tools4 are needed to build module nss. They can be obtained [http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/ here].
|-
|}

'''Notes:'''
# You have to configure with --disable-build-mozilla to enable the use of the prebuild libraries. Place LINUXGCCI{inc,lib,runtime}.zip into <tt>main/moz/zipped</tt>. The files can be reused if the packages were build following the instructions of the previous point. In the latter case they can be found in main/moz/unxlngi6.pro of a successful build.
# Copy the package into <tt>main/moz/download</tt>. The ./configure script will detect the source being present.
# The nss module will be introduced in DEV300m57 (DEV300m57 is the designation of a milestone during the former OpenOffice.org era which has been created in Sep. 2009). nss contains a subset of libraries from Mozilla (the moz module). They are supposed to be more current than those in the moz module. To prevent building nss and instead use the libraries from the moz module one can use the configure switch <tt>--disable-nss-module</tt>. '''This switch will be removed soon!'''
# Use the configure switch <tt>--with-mozilla-build</tt> to tell configure where the tools are installed. For example: <tt>--with-mozilla-build=c:/mozilla-build</tt>
# Please note that CPAN is not able to deal with usernames containing spaces. To work around this fact, when CPAN asks you to specify the CPAN build and cache directory, change the default suggestion to /cpan.
# Apache Ant: Assure a proper ant set-up by downloading and installing ant, in total, from the ant site linked above. If you are a Linux developer, your distro may not have ant setup correctly for building Apache OpenOffice.
# Use <tt>./configure --help</tt> to see all possible configuration options

See also the platform specific requirements for
*[[Documentation/Building_Guide_AOO/Building_on_Windows|Windows]]
*[[Documentation/Building_Guide_AOO/Building_on_Linux|Linux]]
*[[Documentation/Building_Guide_AOO/Building_on_MacOsX|MacOSX]]

==Configuration and bootstrapping==
This is typically done only once after the source code is checked out. Repeat this after changing your mind about options given to configure.

The call to
autoconf
creates the main/configure script from main/configure.in and some other input files.

The set of options/switches given to configure depends on the platform and your choice of features. A typical call starts like this
configure \
--with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 \
--with-epm-url=http://www.msweet.org/files/project2/epm-3.7-source.tar.gz \
It tells configure where to find the source code of external tools dmake and epm.

By default only source code under [http://www.apache.org/legal/3party.html#category-a category A] licenses is compiled and included. Besides the Apache License 2.0 this includes for example BSD and MIT/X11 license. If you want to enable features that rely on third party code under [http://www.apache.org/legal/3party.html#category-b category B] licenses (like MPL, CPL, EPL, etc) then add the option
--enable-category-b

For inclusion of externally hosted dictionary extensions add option
--enable-bundled-dictionaries
Note that dictionaries rely on a category B third party library (hunspell). Therefore <code>--enable-category-b</code> is a prerequisite for <code>--enable-bundled-dictionaries</code>. Dictionaries have a variety of licenses and are bundled without modification: they are not compiled.

The <code>--with-lang</code> option will introduce the build of additional language resources. This switch accepts one or more RFC 1766 language tags as arguments, unfortunately not all languages are supported. Check the <code>[http://svn.apache.org/viewvc/openoffice/trunk/main/solenv/inc/langlist.mk?view=markup solenv/inc/langlist.mk]</code> file for all the currently supported language tags. The environment variable WITH_LANG will then contain the language tags of the additional (en-US will always be build) languages. Example:
--with-lang="de fr"
enables the build of the localized German and French version.

You can run the rat scan while building with option
--with-rat-scan
[[Documentation/Building_Guide_AOO/Rat_Scan|Here]] you can find details.

Finish this step by running
./bootstrap
This will build dmake and epm, download missing source code tar balls of external libraries, and download missing external dictionary extensions.

==Building==
Start by including the environment variables prepared by configure into your current environment with
<tt>source <shell-script-name></tt>
where <shell-script-name> depends on your platform:
{| class="prettytable"
|-
!platform id
!<shell-script-name>
|-
| wntmsci12
| winenv.set.sh
|-
| unxlngi6
| LinuxX86Env.Set.sh
|-
| unxlngx6
| LinuxX86-64Env.Set.sh
|-
| unxmacxi
| MacOSXX86Env.Set.sh
|}
Look into main/set_soenv for more platforms. (search for lines <code>$OUTPATH = "<platform>";</code> and the nearby line <code>$outfile = "<shell-script-name>";</code>. Add the suffix <code>.sh</code> for the bash variant.

If you want to build the whole office and the install sets then
cd main/instsetoo_native
build --all
You may want to experiment with the -P options for multi process builds to reduce the build time.
build --all -P<m> -- -P<n>
tells build to use <code>m</code> processes (build up to <code>m</code> modules in parallel) and <code>n</code> threads for each module.

Building Apache OpenOffice uses a custom build command, build.pl, located in /main/solenv/bin.
You may it helpful to learn more about build options from the [http://www.openoffice.org/tools/tools/build.html Build Documentation]

==Partial Builds==

Building the whole office takes a lot of time. Therefore it may be preferable to build only parts after making changes to the source code.
There are two different types of partial builds:
;Compatible:Can be used only when the code changes do not change exported interfaces. Use with care and only when you know what you are doing.
;Incompatible:Use for code changes that modify exported C++ or IDL interfaces, that modify resources that are used by other modules, or when you are not sure.
:If you are a new developer, you should probably always assume your changes are "incompatible" and follow the instructions for '''Incompatible Build'''.

===Make Systems Used by Apache OpenOffice===

For the following Build sections you should be aware that Apache OpenOffice uses two different '''make''' systems to build its modules.
*The older one is based on dmake
*The other and newer one is based on GNU make. This system is often referred to as gbuild.
When a module contains, among others, a Makefile and a Module_<module>.mk file then it is a gbuild module.

===Compatible Build===

After changing code in module <module> which does not change any exported interfaces do
{|class="prettytable"
|-
!dmake
!gbuild
|-
|
cd <module>
build
deliver
|
cd <module>
make -sr
No explicit call to <code>deliver</code> is necessary for gbuild modules.
|}
to compile and deliver the resulting libraries to <code>main/solver/</code>. You may want to erase the output of a previous compilation:
{|class="prettytable"
|-
!dmake
!gbuild
|-
|
cd <module>
build --from <module> --prepare
or faster (but without the un-deliver)
cd <module>
rm -fr <platform>/
|
cd <module>
make clean
|}

===Incompatible Build===

Modifications that change exported interfaces require not only the module to be rebuild that contains the modified code. All depending modules (dependencies are defined in <code><module>/prj/build.lst</code>) have to be rebuild as well. This is best done from <code>main/instsetoo_native/</code>:
<tt>cd main/instsetoo_native/</tt>
<tt>build --from <incompatible-module> --prepare</tt>
<tt>build --from <incompatible-module></tt>

The second line removes the output of all modules that have to be recompiled. The drawback of this command is that the output of modules which are build via gbuild are not removed. Thus, the following additional command performed after the second one will do the trick:
build --from <incompatible-module> --job="make clean; make clean debug=t" --ignore

===Frequently used options===

In order to add debug information to libraries and executables, add the <code>debug</code> switch to any <code>build</code> or <code>make</code> command:
{|class="prettytable"
|-
!dmake
!gbuild
|-
|
cd <module>
build debug=t
|
cd <module>
make -sr debug=t
|}
Remember that for the gbuild system you have to use the debug flag also when cleaning a module (otherwise eg the wrong precompiled headers are deleted and are not rebuilt):
make clean debug=t

You can force make to rebuild dependency information by first deleting it with the depend option. It is rebuild automatically with the next build:
{|class="prettytable"
|-
!dmake
!gbuild
|-
|
cd <module>
build depend=t
build
|
cd <module>
make -sr depend=t
make -sr
|}

= [http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step Step-by-Step Building Guide for Different Platforms] =
[[Category:Documentation]][[Category:Development]][[Category:Porting]]

Documentation/Building Guide/Building on MacOSX

2013-09-26T16:11:14Z

Talchu: fixed name of folder under trunk (was '/test/extras')

{{Documentation/Building Guide TOC
|ShowNextPage=none
|ShowPrevPage=none
}}

{{DISPLAYTITLE:Building on Mac OS X}}
[[Category:MacOSX]]

__TOC__

= Overview =
This document explains how to build the Apache OpenOffice source code on Mac OS X systems.
{{Template:Documentation/Note|<code>$SRC_ROOT</code> will denote the directory in which the source code of Apache OpenOffice is stored.}}
{{Template:Documentation/Tip|You are advised to check the release notes for the release you are building to inform yourself about changes since previous releases.}}

= Requirements =

To build the office on Mac OS X several requirements/prerequisites have to be fulfilled.

== Mandatory Requirements ==
* '''Mac OS X''' version 10.4 (aka Tiger) or later (if using 10.5 aka Leopard, have a look at [[User:Dyrcona/LeopardBuild#flex]]
* '''Mac 10.4 SDK'''
* For Mac OS X 10.7 (aka Lion), XCode 3.2.6 need be installed.
* '''XCode''' version 2.4.1 or later. If you want to use a newer version than the one that is shipped with your Mac OS X installation media, you need to register at the [https://connect.apple.com/ Apple Developer Connection] site (free of charge) to be able to [http://developer.apple.com/technology/xcode.html download it]. On Mac OS X 10.6 (Snow Leopard), make sure to install the optional 10.4 SDK with XCode.
* '''dmake''', the build environment depends currently on a special patched version of dmake that you can download and build on demand during configure and bootstrap. Or you can provide a prebuilt version and can specify it during configure.
* '''epm''', the build environment depends currently on a special patched version of epm (easy package manager) that you can download and build on demand during configure and bootstrap. Or you can provide a prebuilt version and can specify it during configure.

{{Template:Documentation/Note|XCode 4 is currently not tested because of the missing support in XCode and the office dependency to the 10.4 SDK}}

{{Template:Documentation/Note|Java: On systems < Mac OS X 10.7 Apache OpenOffice does not build yet using Java SDK 1.6.0. If you didn't configure Mac OS X for a 1.6, you don't need to do anything - the default (1.5) is OK. To change the default Java version go to Applications/Utilities/Java and modify accordingly}}

Of course patches to make it build with 1.6 are very welcome and feel free to submit your patches to the dev@openoffice.apache.org mailing list or file issues.

== Optional Requirements ==

=== Prebuilt unowinreg.dll ===

This library is Windows only but will be packed in the Apache OpenOffice SDK to ensure that it is available on all platforms. The library provides some glue code to setup a working UNO environment for UNO client applications connecting to an office and doing some remote automation via API. The library should be stored in ''main/external/unowinreg''. Only necessary for building the SDK.

The library can be downloaded under
* http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll

=== Prebuilt Mozilla archives (based on seamonkey1.1.13) ===

To enable macros/macro security (disabled by default for security reasons), you'll have to put the prebuilt archives of mozilla binaries in the ''main/moz/zipped'' directory.

Note: archives are Intel only for now.

'''Archives to be downloaded''' :

* http://tools.openoffice.org/moz_prebuild/OOo3.2/MACOSXGCCIinc.zip
* http://tools.openoffice.org/moz_prebuild/OOo3.2/MACOSXGCCIlib.zip
* http://tools.openoffice.org/moz_prebuild/OOo3.2/MACOSXGCCIruntime.zip

or from

* http://eric.bachard.free.fr/mac/moz/seamonkey_Intel/MACOSXGCCIinc.zip
* http://eric.bachard.free.fr/mac/moz/seamonkey_Intel/MACOSXGCCIlib.zip
* http://eric.bachard.free.fr/mac/moz/seamonkey_Intel/MACOSXGCCIruntime.zip

== Recommended tools ==

* '''ccache'''
If you intend to build Apache OpenOffice several times, you probably can benefit of ccache since it will speed up your future builds. The first time you make a build with ccache you won't notice it, but the next time the build will go up to five times faster.

You can install it using '''[http://www.finkproject.org/ Fink]'''. It is simply named "ccache". For '''[http://www.macports.org/ MacPorts]''' users the package is called "ccache".

If you don't use fink, you can download and build it yourself using the source provided at http://ccache.samba.org/

There are two ways to enable ccache - one is to set environment variables, the other way is to use symlinks.

Using environment variables:
export CC="ccache gcc"
export CXX="ccache g++"

Using the symlink approach:
# create a directory for the links
mkdir ~/bin
# create the symlinks pointing to ccache with the name of the compiler
ln -s /path/to/ccache ~/bin/gcc
ln -s /path/to/ccache ~/bin/g++
ln -s /path/to/ccache ~/bin/cc
ln -s /path/to/ccache ~/bin/c++
# no all you need to enable ccache is to prepend ~/bin to your PATH
$ export PATH=~/bin:$PATH

for both methody, you can add the "export ..." lines to your ~/.profile - that way you don't need to manually set it when building. You can still temporarily disable ccache (export CCACHE_DISABLE=1) in case you don't want to use it.

Since OOo is rather huge, you should increase the cache-size to 1 GB or more
ccache -M 1G

* '''subversion''' version '''1.5.4 or later'''
Since OOo's source code is managed using Subversion currently, you also need the svn client to checkout sources (otherwise you would be bount to source-tarballs that aren't generated that frequently). You can either compile yourself or use the subversion universal binaries from the [http://subversion.tigris.org subversion project] Version 1.5.4 or later is required because of important fixes related to the merge-feature.

== Get the source and prepare to build it ==

=== Get the source from SVN ===

You need about 4.7 GB for a checkout from the svn repository. Building the source requires another 5GB. 

* '''check out the latest source from svn'''

svn co https://svn.apache.org/repos/asf/openoffice/trunk aoo

=== One-Time preparation and scripts ===

Apache OpenOffice build environment is configured using the open-source configuration-management package 'autoconf'. So you can do your beloved './configure' command, is now done in the '''main''' source directory.

To save the configure parameters and use them with different milestones it is useful to create your own build script to configure the environment and to trigger the build.

The directory structure when you have checked out the sources from svn looks like:

aoo/
aoo/main
aoo/extras
aoo/test
aoo/ext_libraries
aoo/ext_sources

Move into '''main''' and configure a minimal environment to build your first version of Apache OpenOffice:

cd main

Run the autoconf command to prepare a new configure based on the latest changes in configure.in

autoconf

Run configure

./configure --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 --with-epm-url=http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz

This commands prepares a minimal environment to build the office without any category-b enabled external libraries. A pure Apache license compatible version. See also the configure switches ''--with-dmake-path'' and ''--with-epm'' to specify prebuilt versions of dmake or epm.

Finally you should run bootstrap to trigger further preparations and to create platform specific shell script to setup a working build environment. On Mac OS x for example '''MacOSXX86Env.Set.sh''' on a Intel based system.

=== Build environment with enabled category-b dependencies ===

To prepare a build environment that provides more features and make use of further external libraries which are under copyleft but viral licenses you have to explicitly enable this '''category-b''' components.

./configure --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 \
--with-epm-url=http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz \
--disable-build-mozilla \
--enable-verbose \
'''--enable-category-b'''\
--enable-minimizer\
--enable-presenter-console\
--enable-wiki-publisher

===Example build script to simplify user specific configurations===
As mentioned before to save the configure parameters and use them with different versions it is useful to create your own build script to configure the environment.

Create 'build.sh' (to be written) :

<pre>
#! /bin/bash

echo "### checking for unowinreg.dll ... "
if [ ! -e ./external/unowinreg/unowinreg.dll ]; then
wget -O external/unowinreg/unowinreg.dll http://tools.openoffice.org/unowinreg_prebuild/680/unowinreg.dll
else
echo " unowinreg.dll found"
fi

echo "### checking for moz prebuild libs ... "
if [ ! -e ./moz/zipped/MACOSXGCCIinc.zip ]; then
wget -O ./moz/zipped/MACOSXGCCIinc.zip http://www.openoffice.org/tools/moz_prebuild/OOo3.2/MACOSXGCCIinc.zip
wget -O ./moz/zipped/MACOSXGCCIlib.zip http://www.openoffice.org/tools/moz_prebuild/OOo3.2/MACOSXGCCIlib.zip
wget -O ./moz/zipped/MACOSXGCCIruntime.zip http://www.openoffice.org/tools/moz_prebuild/OOo3.2/MACOSXGCCIruntime.zip
else
echo " moz prebuild libs found"
fi

if [ ! -e ./configure ]; then
echo "### autoconf ..."
autoconf
else
echo "### autoconf ..."
rm ./configure
autoconf
fi

echo "### Configure"
./configure --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 --with-epm-url=http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz

#./configure --with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b %Y)") - Rev. $(echo $(svn info) | sed -e 's/^.*Last Changed Rev: //g' -e 's/ .*//g')" \
--disable-build-mozilla \
--enable-verbose --enable- category-b --enable-minimizer --enable-presenter-console --enable-wiki-publisher \
--with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 \
--with-epm-url=http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz

./bootstrap
</pre>

Put this script into ~/bin and make sure it is executable :

chmod ug+x ~/bin/build.sh

We used the bash shell in all example, since to our belief users of the C-shell are smart enough to figure out the differences anyway. If you want to dig deeper into the build process, please have a look at the description [http://tools.openoffice.org/build_env.html OpenOffice.org's Build Environment].

== Doing the build ==

After running configure and bootstrap we should have a working build environment and all necessary scripts should have been created. From now on you can use '''MacOSXX86Env.Set.sh''' to prepare a new shell with a working build environment.

=== On Mac Intel ===

source MacOSXX86Env.Set.sh
cd instsetoo_native
build --all

or

build --all -P4

=== On PowerPC ===

source MacOSXPPCEnv.Set.sh
cd instsetoo_native
build --all

or

build --all -P2

=== Comments on above ===

'''TODO TODO TODO ....'''

if you run into trouble with --dlv_switch (see: {{Bug|77360}})

The main purpose of the '''bootstrap''' script is to build (if necessary) the dmake utility used. Dmake once was a unix make-clone made by wticorp but got incorporated into OpenOffice since it was orphaned. For more information about dmake, it's history and manpage have a look here: http://tools.openoffice.org/dmake/index.html

Sourcing MacOSXPPCEnv.Set.sh is very important not only for building but also for '''running''' svdem later on. Here all the Environment-Variables for the Build will be set up. For a detailed description see [[Environment_Variables]]. Please note that on Intel machines, 'MacOSXPPCEnv.Set.sh' should be substituted with 'MacOSXX86Env.Set.sh'.

This Build process takes on my box (Dual 1.8 GHz G5, 1.5GB RAM) roughly 10 hours, and 3 to 6 hours on Mac Intel (3:30h on a 2GHz DualCore INTEL iMac). Be patient.

If you want to see how the progress on that build is you can use two '''build''' options to get a comfortable view:

build ... <see above> ... --html --html_path /Users/$USER/Sites

where $USER is your user name. Then you can load in Firefox (not Safari!) the HTML file '''unxmacxi.pro.build.html''' via the in Mac OS X included Apache web server or diretctly form the directory ''/Users/$USER/Sites/''. This file is automatically being updated and is showing the status of the build and also the time needed since the build started.

If you build on Snow Leopard (aka Mac OS X 10.6): Set DYLD_INSERT_LIBRARIES to point to the correct libsqlite3.dylib:
<pre>
DYLD_INSERT_LIBRARIES=/usr/lib/libsqlite3.dylib
</pre>

== '''Installing, preparing and running OpenOffice.org''' ==

===''' Find the Bundle''' ===

Once the build completed, the final product ( en-US version ) is named : OOo_3.0.0_*_MacOSXIntel_install.dmg ( for version 3.0beta e.g.)

And is located in instsetoo_native/unxmacxi.pro/OpenOffice/dmg/install/en-US directory ( replace en-US with your locale )

[[Image:Bundle_Location3.0beta.jpg]]

=== '''Install the new Build''' ===

* double click on the *.dmg icon
* drag the OpenOffice.org icon into a folder of your choice

=== '''Run the new Build''' ===

* double click the application icon in that folder

=== '''Screenshots''' ===

Now you can start to work with this [[Aqua_Screenshots | amazing productivity suite]].

== '''Contribute by finding, isolating, debugging or solving issues''' ==

=== '''Isolate a problem''' ===

==== '''Reduce a problem''' ====

* make a problem reproducable
* reduce it to a test case that is as small and simple as possible
* if a problem is specific to a document then please attach it to the issue. A mininal excerpt of the document that still shows the problem is even better.
* a screenshot of is a good idea if it clearly shows the problem

==== '''Using application switches''' ====

Application switches are often valuable for isolating a problem. Most of OpenOffice.org's options can be found its Tools->Options menu.
 
Some switches are so special that there is no user interface to change them. They are only useful for debugging and isolating a problem, but they are very valuable a that. So a developer might suggest to isolate a problem by setting an environment variable before running the application. E.g. for isolating problems with the menubar a developer might suggest to set the environment variable [[AQUA_NATIVE_MENUS]] to false. This is done by typing these commands into a terminal:
* cd <INSTALL_DIR>/OpenOffice.org/Contents/MacOS
* export AQUA_NATIVE_MENUS=false
* ./soffice.bin

==== '''Provide a call stack for crash problems''' ====

Please note that bugs involving crashes should provide a description of how to reproduce the problem and a callstack.
There are several ways to provide the callstack:
* the preferred method is to use OOo"s builtin [[CrashReporting|crash reporting tool]]
* developers may provide a [[Providing_a_gdb_backtrace | gdb backtrace]] of the problem
* if the above two methods don"t work then please attach a file with the details provided by the AppleCrashReporter

=== '''Check against known issues''' ===

Check the list of [http://www.openoffice.org/issues/buglist.cgi?issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=&chfieldvalue=&short_desc=&short_desc_type=fulltext&long_desc=&long_desc_type=fulltext&issue_file_loc=&issue_file_loc_type=fulltext&status_whiteboard=&status_whiteboard_type=fulltext&keywords=aqua&keywords_type=anytokens&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time&Submit+query=Submit+query open issues]

=== '''Report a new issue''' ===

Report [http://qa.openoffice.org/issue_handling/pre_submission.html new issues] after you have [[AquaBuild#Isolate_a_problem | isolated the problem]]

=== '''Debug a problem''' ===

Debugging problems is often easier in an development environment:
<ul>
<li>With XCode: [[MacOSX_Debug_OpenOffice.org_using_XCode]]</li>
<li>With Xemacs: [http://www.mikesicotte.com/2007/02/21/debugging-ooo-with-xemacs-and-gdb Michael Sicotte's blog entry]</li>
</ul>

Please note that XCode still has some problems with the executable named soffice.bin (because of the dot in the name). The issue has been reported to xcode-users list.

== '''Current Work in progress (Aqua specific work only)''' ==

With OOO300 the Aqua port became a mainstream port, so most Aqua issues are handled in regular GSL-Layer childworkspaces instead of dedicated Aqua CWSses. Other CWSses that are purely Aqua specific are being tracked below:

* '''{{CWS|ogltrans4mac|DEV300}}''' : Implement the 3D (OpenGL) transitions in Impress ( see : [[Mac_OS_X_Porting_-_OpenGL_transitions| OpenGL transitions on Mac OS X ]] )

==='''Child WorkSpaces in development''' ===

* '''{{CWS|appleremote03|DEV300}}''' : use the contextual menu in presentation mode with Impress. preliminary step

* '''{{CWS|hotmac|OOO300}}''' : fix memory deallocation problems in exit()

* '''{{CWS|macosxscanner01|DEV300}}''' (planned)

All patches that developers have that need testing or peer review should be added here.

==='''Child WorkSpaces in testing (closed for development)''' ===

*'''{{CWS|macmiscfixes}}''' : misc fixes for mac

*'''{{CWS|maccrashrep}}''' : support crash reporting for OSX builds

*'''{{CWS|quicklookplugin01}}''' : a plugin for the QuickLook system available in MacOSX from versions 10.5 onwards

==='''Child WorkSpaces waiting for integration''' ===

* '''{{CWS|appleremote02|DEV300}}''' : improve the Apple Remote use with Impress (use MEDIA_COMMAND stuff, improve code robustness, and portability )

==='''Child Workspaces integrated into OpenOffice's trunk''' ===

A historical overview of [[Aqua_Integrated_CWS | old Aqua specific ChildWorkspaces]].

== '''Known build issues '''==
*'''Tiger''': no known issues
*'''Leopard''': no known issues
*'''Snow Leopard''': no known issues
*'''Lion''': no known issues
*'''Mountain Lion''': no known issues

<div align="left" style="color:grey; font-size:12px">[[AquaBuild/Some Background | '''Some Background (what is a CWS, EIS) (click me to know more) ''']]</div>

== '''External links''' ==
* [https://issues.apache.org/ooo Apache OpenOffice Issuezilla] : a database of bugs, changes and enhancements
* There are [[MacOSXPortMeetings | regular meetings]] on IRC (archives are [[Previous_Mac_Meeting_logs | available]]).
* Apache OpenOffice has a complicated code base. [[Source_code_directories | Here]] is an overview.
* the official Apache OpenOffice blog is at [https://blogs.apache.org/OOo/]
* [http://www.cocoadev.com Cocoadev] provides great resources to get up to speed in Cocoa development
* Pierre Chatelier's excellent [http://ktd.club.fr/programmation/objective-c.php Objective C for C++ developers] is available in both english and french versions
* Details about OSX's [http://developer.apple.com/cocoa Cocoa API] are available in the XCode documentation

[[Category:Aqua]]
[[Category:Build_System]]

Documentation/Building Guide/Basic Concepts

2013-09-23T23:41:45Z

Talchu: /* Partial Compatible/Incompatible Builds */

{{Documentation/Building Guide TOC
|ShowNextPage=none
|ShowPrevPage=none
}}
{{DISPLAYTITLE:Basic Concepts}}

To understand all concepts, techniques and the terminology described in this guide, make sure you understand the following basic concepts.
__TOC__
== Terminology ==
{| class="prettytable"
|-
! Term
! Description
|-
| SRC_ROOT
| The environment variable containing the path to the directory of the source code. '''Example:''' /home/john/projects/ooo/builds/OOO310_m11
|-
|}

== Branches ==
=== Development branch ===

The current development branch is located at:

http://svn.apache.org/viewvc/openoffice/trunk/

This is where most development is done. It has the most open policy for applying patches and it is typically where new features are developed and debugged.

The good side to this is that you have the latest features, the down side is that you get the side effects of the changes.

=== Stable branch, specialized branches ===

The latest stable release as well as branches that are used for development of some specialized aspect are located at:

http://svn.apache.org/viewvc/openoffice/branches/

A stable branch is base for a release build of the OpenOffice product. This is where bug fix tracking takes place. The policy on these branches are to fix functional errors only.

The good side is that any patches are more thoroughly vetted before going into a stable release. Therefore you have fewer mystery bugs. The downside is that there are fewer features and some bug fixes are already in the developer release.



== Modules ==
The source code directory contains a lot of folders, each one representing a module. A module provides an application, a function, or simply just a collection of classes. A module is the smallest unit of the office suite that can be built.

Modules correspond to the directories under the top-level directory of the source tree. For example, the Writer project includes the sw, starmath, res modules, etc.

There are many dependencies between the modules, and the modules must build in a particular order. Module prerequisites are described in first line of the file prj/build.lst for example:

froddo: /data2/office/sw/prj$ cat build.lst
sw sw : connectivity svx stoc uui sch NULL

We find that sw depends on connectivity etc. These modules in turn depend on others creating a large complex dependancy tree.

{{Template:Documentation/Note|For more information on modules, see:
* [[Source code directories]]
* [[Module Build Order]]
* [[New Module]]}}

== Build Styles ==

=== Full Builds ===
Developers typically perform a full build of OpenOffice in order to build their modules. A full build also recompiles all of the source code. It can take up to a few hours to perform a full build of OpenOffice.org even on modern workstations. However using tools such as distcc and ccache can have dramatic time improvements.

=== Partial Compatible/Incompatible Builds ===
To avoid the need of a time-expensive complete re-build each time a change in the code is introduced, the developers are asked to introduce only ''binary compatible'' changes in the code unless it is agreed with the project owner. This means that the changes made are of such a nature that no recompilation of further dependent modules become necessary (inserting a new, non-virtual method in a C++ class would be an example of such a binary compatible change). The office suite will then be re-compiled as a so-called ''respin build'' before the next 'master' s declared. A respin build obeys only weak dependencies, i.e. dependencies within a module. Using weak dependencies allows you to, for example, to modify a base library header file without needing to perform a full build. Since a respin build relies on binary compatible changes, modules can be build in parallel, and the build takes much less time (a few hours) in contrast to a full build.

{{Template:Documentation/Note|By contrast, ''binary incompatible'' changes require a full build. For reasons of efficiency, this is allowed only with the approval of the project owner.}}

=== Snapshots Builds ===

OpenOffice employs a buildbot for snapshot builds. However, the output of these builds are for developer use/information only. They are not advertised for public consumption -- beta testing.
We follow Apache rules for the announcement of releases.

== Source and Output Trees ==
OpenOffice.org developers work in parallel on all platforms. The source code for all platforms is identical, with the exception of the code for the interface to the operating system and window managers. This allows you to build for the different platforms simultaneously from a single ''source tree'', i.e. the directory structure that stores all of the source code for the office suite.

The <code>solenv</code> tree contains the environment tools that the build process uses, for all supported platforms. Formerly it also included the platform-specific build tools. Now these build tools are created with a <code>bootstrap</code> script created with the <code>configure</code> script.

When building multiple modules, these steps are taken for each module:
* The build process generates files from the ''source tree'' into the ''output tree'' of the module (this is a directory named after the platform, e.g. unxlngi6.pro for 32-bit Linux)
* After the module has been build, the results are copied to the ''solver'', a directory sitting next to the top-level modules in the <code>SRC_ROOT</code>. This step is called <code>deliver</code> (there is a tool with the same name). Modules cannot link/compile against the ''output'' directory of other modules, they only compile/link against objects in the solver.

When you run <code>bootstrap</code>, the <code>solver</code> directory is created. Initially, the <code>solver</code> directory is empty. The build process populates this directory. The build process delivers all binary files, shared libraries, and dynamic link libraries to solver.

When you want to build a specific project, you only need the sources of the relevant SVN modules and the output tree <code>solver</code>. You do not need the entire source tree, though typically a developer will check out one of the branches and build it from scratch.

{{Template:Documentation/Note|For more information on the solenv and solver trees, see the [http://tools.openoffice.org/ Tools] project.}}

{{PDL1}}

Pootle User Guide/General Problems

2013-09-19T23:10:36Z

Talchu: /* The English word is ambiguous */

Pootle User Guide/Translation AOO User Interface

2013-09-19T21:04:33Z

Talchu: spelling

{{Documentation/MasterTOC
|booktitle=[[Pootle_User_Guide|Pootle User Guide]]
|toccontent=*[[Pootle_User_Guide/Registration_and_Login|Registration and Login]]
*[[Pootle_User_Guide/Online_Pootle_User_Interface|Overview Pootle UI]]
*[[Pootle_User_Guide/Offline_Translation|Offline Translation]]
*[[Pootle_User_Guide/Quality_Assurance|Quality Assurance]]
*[[Pootle_User_Guide/Release_Localized_Build|Releasing a Localized Build]]
*[[Pootle_User_Guide/Technical_Helpers|Technical Helpers]]
*[[Pootle_User_Guide/Translation_AOO_User_Interface|Translation of the User Interface]]
*[[Pootle_User_Guide/Translation_Built-in_Help|Translation of the Built-in Help]]
*[[Pootle_User_Guide/General_Problems|General Problems]]
}}

{{DISPLAYTITLE:Translation of the AOO User Interface}}

==Accelerator keys (mnemonics)==
'''ToDo'''

<''see mail from Andrea; explain difference with shortcuts like CTRL-O''>

==How to find a string in my OpenOffice-Installation==
'''ToDo'''

<''Problem description by example''>

<''get the application module, link to the section "What File Name and Location Can Tell You" on this page''>

<''Search identifier in source to get other texts from the same dialog or menu.''>

<''Verify a candidate by the identifier''>

==How to find an UI string in Pootle==
'''ToDo'''

<''Problem description by example''>
<''Using the information from the extended tip''>

===Using a KeyID===
Get a keyID-Build as described in section [[Pootle_User_Guide/Technical_Helpers#Getting_a_KeyID-Build| Getting a KeyID-Build]].

Use a keyID-Build to find a string from the UI in Pootle this way:
# Lunch the keyID-build and look up the keyID of the string.
# Get the file localize.sdf in folder <tt>/trunk/extras/l10n/source/'''kid'''/</tt>. Download the file and open it in an editor, or open it directly in your browser. The file large, so it takes a while till your browser shows it. To get the file you can use OpenGrok or ViewVC as well, see section [[Pootle_User_Guide/Technical_Helpers#Search_in_the_Source_Code|Search in the Source_Code]].
# Use the search feature of your editor or browser respectively to find the row, which contains the keyID.
# The fifth column from left contains the identifier of the string, as it is used in source code. Copy it.
# Enter this identifier in the search field in Pootle and check ''location'' in the search check boxes. Start search.

==What File Name and Location Can Tell You==
You will see in the following examples, that the filename and location can tell you a lot. Imagine you need to work on the string "line spacing". A search will give you numerous results. Here are some of them, try to find the part in the UI ;)

'''1'''

[https://translate.apache.org/da/aoo40/translate.html#unit=12961852 Example unit=12961852]

File:<tt>cui/source/tabpages.po</tt>

The file name tells you from which source directory the strings are collected. Sadly the total overview of the directories at [[Source_code_directories]] is not updated to AOO4. <''A new version for AOO4 is needed.''>

<tt>cui</tt> derives from ''common user interface'' and contains parts that are used by several modules.

<tt>tabpages</tt> are pages in a dialog.

Location: <tt>paragrph.src#RID_SVXPAGE_STD_PARAGRAPH.FL_LINEDIST.fixedline.text</tt>
*<tt>paragrph.src</tt> The file, which contains the string. Most strings from the UI are defined in <tt>.src</tt> files. Looking into the source you will see, that this file contains the structure of the dialog. The name "paragrph" sounds like "paragraph", a strong indicator, that this "line spacing" belongs to text formatting. *<tt>RID_SVXPAGE_STD_PARAGRAPH</tt> The string belongs to a dialog page about paragraphs. The letters RID are an acronym for ''resource identifier''.
*<tt>FL_LINEDIST</tt> <tt>FL</tt> might derive from ''fixed line'' and <tt>LINEDIST</tt> from ''line distance''.
*<tt>fixedline</tt> Now your are sure, it is a fixed line. The string is used to group the dialog page.

Find ''Show''|''Hide'' and ''More''|''Less'' links directly above and below the active translation record. In this light green area, you see strings, which are near to the current one in the source code. They likely belong to the same dialog page.

'''2'''

[https://translate.apache.org/da/aoo40/translate.html#unit=12977489 Example unit=12977489]

File: <tt>starmath/source.po</tt>

The string belongs to the formula editor MATH.

Location: <tt>smres.src#RID_DISTANCEDIALOG.7.2.string.text</tt>
*<tt>smres.src</tt>: "smres" perhaps stands for "star math resource".
*<tt>RID_DISTANCEDIALOG</tt> The string belongs to a 'distance dialog'.
*<tt>.7.2</tt> It is a multi-part dialog. On the first part choose the 7th string and in the next part the 2nd string.
*<tt>string</tt> "string" is rather generic, here it is an item in a drop-down list.

'''3'''

[https://translate.apache.org/da/aoo40/translate.html#unit=12980472 Example unit=12980475]

File: <tt>svx/source/sidebar/paragraph.po</tt>

The string belongs to something with paragraphs and is part of the sidebar.

Location:<tt>ParaPropertyPanel.src#RID_SIDEBAR_PARA_PANEL.TBX_LINESP.BT_BTX_LINESP.toolboxitem.text</tt>

*<tt>ParaPropertyPanel.src</tt> The string is in the paragraph panel of the Properties deck.
*<tt>RID_SIDEBAR_PARA_PANEL</tt> A resource identifier for the paragraph panel of the sidebar.
*<tt>TBX_LINESP</tt> It belongs to the toolbox ''line spacing''. The property panel has several toolboxes, in most cases drawn in a little bit lighter color with a hairline border. Such toolbox has an internal titel text, but that text is not localized and does not show up on Pootle.
*<tt>BT_BTX_LINESP</tt> There exist no general rule how to design identifiers. The position in the string shows you, that it is a toolbox item. A toolbox item can be a simple button, but may contain more controls including metric fields.
*<tt>toolboxitem</tt> The string is a kind of title for the toolboxitem, but it is only visible as simple tooltip. You need to hover with the mouse over the icon to see the string.

'''4'''

[https://translate.apache.org/da/aoo40/translate.html#unit=12981827 Example unit 12981827]

File: <tt>sw/source/ui/app.po</tt>

In this case you not really lucky. "app" indicates, that it is a collection of strings which belong to more or less independent items. At least you know from the part <tt>sw</tt>, that it belongs to Writer.

Loation: <tt>mn.src#MN_TEXT_ATTR.MN_FORMAT_LINESPACE.menuitem.text</tt>
*<tt>mn.src</tt> "mn" derives from menu.
*<tt>MN_TEXT_ATTR</tt> It is a menu for text attributes
*<tt>MN_FORMAT_LINESPACE</tt> A submenu for line spacing
*<tt>menuitem</tt> It is a text, that is shown in a menu. If you looked into the source file, you would guess that it is the context menu of text in Writer.

'''5'''

[https://translate.apache.org/da/aoo40/translate.html#unit=12969066 Example unit 12969066]

File:<tt>officecfg/registry/data/org/openoffice/Office/UI.po</tt>

This belongs to the Configuration data. They will be stored in the installation directory in share/registry. The user configurations extend these settings.

Location:<tt>GenericCommands.xcu#..GenericCommands.UserInterface.Commands..uno_SpacePara1.Label.value.text</tt>
*<tt>GenericCommands.xcu</tt> This file contains those commands, which are available in more than one module. For example "save the document" is available in all modules. The file format is XML.
*<tt>.GenericCommands.UserInterface.Commands.</tt> The elements in the xml format are nested nodes. Compare it with the source extract shown below.
*<tt>uno_SpacePara1</tt> This is the inner node. It is the name of the command. The underscore stands in place of a colon.
*<tt>Label</tt> and <tt>value</tt> correspond directly to the notation of the xml file.
<syntaxhighlight lang="xml">
<oor:component-data oor:name="GenericCommands" ...>
<node oor:name="UserInterface">
<node oor:name="Commands">
<node oor:name=".uno:AVMediaPlayer" oor:op="replace">
<prop oor:name="Label" oor:type="xs:string">
<value xml:lang="en-US">Media Pla~yer</value>
</prop>
<prop oor:name="Properties" oor:type="xs:int">
<value>9</value>
</prop>
</node>
...
<node oor:name=".uno:SpacePara1" oor:op="replace">
<prop oor:name="Label" oor:type="xs:string">
<value xml:lang="en-US">Line Spacing: 1</value>
</prop>
...
</node>
</syntaxhighlight>
The part <tt>xml:lang="en-US"</tt> causes, that the string <tt>Line Spacing: 1</tt> is localized and shows up in Pootle.

The command name is used to reference the command. Such <tt>.uno</tt> commands are used in several places in the application.
* As Button in a toolbar. The string is shown as simple tooltip and as default text. It is always the same string used, regardless of the toolbar.
* As menu item. The string is used as menu item text. Consider this when translating the term, so that it does not become to wide.
* When you record a macro, the dispatcher uses the command name. Programmer uses it when writing extensions using the API.
* As reference for the extended tips in the built-in help.
* When you customize a toolbar, you see the command name in the lower part of the description.

{{DISPLAYTITLE:Translation of the AOO User Interface}}

[[Category:Localization]]
[[de:DE/Pootle_User_Guide]]
[[it:IT/Localizzazione/Pootle]]
[[ja:JA/translation/Pootle_User_Guide]]
[[ko:KO/Pootle 사용자 가이드]]
[[nl:NL/Localisatie/Pootle gebruikersgids]]