Skip to content

MantisBT

Jump to bottom Edit New page
mhabrnal edited this page Nov 19, 2014 · 53 revisions

MantisBT reporter

Function of the MantisBT reporter has to be similar to function of the reporter-bugzilla. Therefore, in the first part it is described how the reporter-bugzilla works.

How the reporter-bugzilla works

The reporter-bugzilla searches for potential duplicate reports by looking for a bug report with matching 'Component', 'Product' and 'Whiteboard' equals to 'abrt_hash:$(duphash)'. In the case there were found some potential duplicates, 'Product version' is added to the query parameters and another search is performed. This second search returns a duplicate bug report if exists. If no duplicate bug report exist the new bug report is created (id of duplicate report are attached as a comment to this new bug report). reporter-bugzilla can also fill the Bugzilla URL field with an URL to another bug tracker (e.g. ABRT Server report URL) (see --tracker command line argument) and add a new comments and attachments to the bug report.

The main functions of the reporter-bugzilla

  • find duplicate and potential duplicate bug reports
  • create a new bug report
  • add comment to existing bug report
  • add attachment to existing bug report
  • add URL to another bug tracker (e.g. ABRT Server)

MantisBt reporter

MantisBT reporter should provide the same functionality as the reporter-bugzilla. This section provides information and implementation details of the main required functions of the MantisBT reporter which are related to the main reporter-bugzilla functions.

note: In the MantisBT is a bug report named as a report issue.

Find duplicate and potential duplicate report issues

To find duplicate and potential duplicate report issues we need a function from Mantis SOAP API which is able to find desired report issues based on defined information (namely: 'Category', 'Project', 'OS Version' and abrt_hash:$(duphash)).

There are a few problems:
  1. There is no MantisBT SOAP API function for search by defined parameters.
  2. There is no field where to store the abrt_hash:$(duphash) as in the Bugzilla Whiteboard.

Ad 1 In MantisBT SOAP API are only defined methods to filter report issues based on predefined filters which are stored in database. There is no method to add new filter to database or edit an existing one. These filters are not parameterizable. There is a possibility to create a patch to MantisBT which adds a new SOAP API method for searching within report issues by defined parameters (for inspiration see https://www.mantisbt.org/forums/viewtopic.php?f=4&t=4666&p=12038&hilit=soap+search#p12038) and negotiate with CentOS BT in order to apply this patch. It is also the possibility to create a bug for discussion on this topic with people from the CentOs BT.

Ad 2 It is possible to define a custom field (e.g. 'Abrt Hash') or use an existing field 'Additional Information'. In the first case it is necessaru to negotiate with CentOS BT added this custom field. In the second case the 'Additional information' field is sometime used for other purposes. For example are there some url, versions of other packages that were used in crash time, some bash commands.

Solusion Adding some useful plugins to the MantisBT which will provide the required functionality. It is add custom field to store abrt duphash and add search method which provide search by the duphash within all MantisBT issues. See: http://lists.centos.org/pipermail/centos-devel/2014-November/012370.html

Create a new report issue

In this section it is described what information must be filled and what information are optional to create Mantis Bug Tracker issue. Also described what files from problem data directory created by ABRT (see https://rmarko.fedorapeople.org/abrt-python/properties.html) are related to those information.

Required fields

To create MantisBT issue is required to enter these dates:

  • Project - Name of project (CentOS-6, CentOS-7) - ABRT dd - os_info (it is similar to the REDHAT_BUGZILLA_PRODUCT + REDHAT_BUGZILLA_PRODUCT_VERSION for Bugzilla) It is necessary to negotiate with CentOS add the CentOs Bug Tracker product name to the /etc/os-release
  • Category - ABRT dd: component (Field Category is similar to the filed component in Bugzilla)
  • Summary - Format of this field is defined by the format configuration file stored in the /etc/libreport/plugins/. For example, summary format for Bugzilla is defined in the /etc/libreport/plugins/bugzilla_format.conf. ABRT dd (for Bugzilla): pkg_name, crash_function, reason
  • Description - Content of this fields is similar to the Bugzilla field Description.

Optional fields

It is possible to fill these following optional items:

  • Platform - ABRT dd: architecture
  • OS - ABRT dd: related to NAME item from os_info
  • OS Version - ABRT dd: related to VERSION item from os_info
  • Product Version - ???

The following table describes items of the Bugzilla and items of the MantisBT and relationship between them.

Bugzilla MantisBT
*Product *Project (OS + OS Version)
*Component *Category
*Version OS Version
*Summary *Summary
Description *Description
Severity **Severity
Hardware Platform
**OS OS
**Priority **Priority
  **Reproducibility
  **Steps To Reproduce
  Additional Information
  **View Status
  Product Version

(* = Required Field)

(** = Abrt does not use this field)

Comparison of problem description in the Bugzilla and MantisBT. In the Bugzilla is a description of the problem associated with Description field. This field contains the following template: 

Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

In the MantisBT is this field dividet into three, namely Description, Steps To Reproduce and Additional Information.

Fields formatting

In this section is described formatting of some string fields (namely: 'Summary', 'Description', 'Steps To Reproduce' and 'Additional information').

  • Summary field

Formatting of 'Summary' field for the Bugzilla is configured in the /etc/libreport/plugins/bugzilla_format.conf config file. For the MantisBT will be used the same format as for the Bugzilla (formatting definition: [abrt] %pkg_name%[[: %crash_function%()]][[: %reason%]][[: TAINTED %tainted_short%]]). For example the 'Summary' for will-crash package on the Bugzilla is follows:

[abrt] will-crash-0.5-2.fc20: main: Process /usr/bin/will_segfault was killed by signal 11 (SIGSEGV)
  • Description field

In case the field 'Additional information' will be used to store URLs to another servers (see section Add URL to another bug tracker) we will use the same formatting as for the Bugzilla that already contains Aditional info section.

solution The field 'Additional information' will NOT be used to store URLs to another servers because there will be a new custom field to store URLs to another servers. (see http://lists.centos.org/pipermail/centos-devel/2014-November/012370.html). Field 'Additional information' in the MantisBT will be used to store section 'Additional info' from the Bugzilla's 'Description' field.

The default formatting for Bugzilla Description field is follows: 

Description of problem:: %bare_comment

Version-Release number of selected component:: %bare_package

Additional info:: \
    -pkg_arch,-pkg_epoch,-pkg_name,-pkg_release,-pkg_version,\
    -component,-architecture,\
    -analyzer,-count,-duphash,-uuid,-abrt_version,\
    -username,-hostname,-os_release,-os_info,\
    -time,-pid,-pwd,-last_occurrence,-ureports_counter,\
    %reporter,\
    %oneline

Truncated backtrace:: %bare_%short_backtrace

For example the 'Description; for will-crash package on the Bugzilla is follows: 

Version-Release number of selected component:
will-crash-0.5-2.fc20

Additional info:
reporter:       libreport-2.1.7
backtrace_rating: 4
cmdline:        will_segfault
crash_function: main
executable:     /usr/bin/will_segfault
kernel:         3.12.0-0.rc0.git21.1.fc21.x86_64
runlevel:       3 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (1 frames)
 #0 f at will_stackoverflow.c:5
  • Step To Reproduce

In the Bugzilla is not used Step to reproduce description so we do not use the 'Step To Reproduce' field in the MantisBT too.

note There is one problem that must be solved and it is Formalize bug formatting API (see https://github.com/abrt/libreport/issues/303).

SOAP API Methods

To implement this functionality will be used method mc_issue_add from the MantisBT SOAP API. This method has three arguments ('username', 'password', 'issue'), where 'username' and 'password' are strings and 'issue' is a IssueData type (see https://bugs.centos.org/api/soap/mantisconnect.php?wsdl). This method returns id of new created report issue.

Example of adding a new issue via MantisBT SOAP API using Python 

from suds.client import Client

url = "http://localhost/mantisbt/api/soap/mantisconnect.php?wsdl"
client = Client(url)

issue = client.factory.create('IssueData')
issue.project.name = $project_name
issue.project.id = $project_id
issue.summary = $summary
issue.description = $description
issue.category = $category

issue_id = client.service.mc_issue_add($username, $password, issue)

Add comment to existing report issue

In the mantisBT is comment called as note. To add note to existing report issues will be used method mc_issue_note_add. This method has a four arguments ('username', 'password', 'issue_id' and 'note'). For more information see bugs.centos.org/api/soap/mantisconnect.php?wsd). Where 'username', 'password' are strings, 'issue_is' is a integer and note is a IssueNoteData type. This method returns id of created note.

Example of adding a new note to an existing issue via MantisBT SOAP API using Python 

from suds.client import Client

url = "http://localhost/mantisbt/api/soap/mantisconnect.php?wsdl"
client = Client(url)

note = client.factory.create('IssueNoteData')
note.text = "Testing mc_issue_note_add"

note_id = client.service.mc_issue_note_add($username, $password, $issue_id, note)

Add attachment to existing report issue

To add attachment to existing report issue will be used method mc_issue_attachment_add. This method has six arguments ('username', 'password', 'issue_id', 'name', 'file_type' and 'content'), where 'username', 'password', 'name' and 'file_type' are strings, 'isuue_id' is an integer and 'content' is base64Binary type.

if we want to add a text attachment to existing issue, it is necessary to encode this text to the base64 format before it sends.

Add URL to another bug tracker (e.g. ABRT Server)

There is no URL field in the MantisBT like in the Bugzilla. There is a possibility use 'Additional information' field to store URLs to another bug trackers (e.g. ABRT Server report URL). This information is added at the time of creating report issue. In the case of using 'Additional information' field is used method mc_issue_add.

solution The field 'Additional information' will NOT be used to store URLs to another servers because there will be a new custom field to store URLs to another servers. (see http://lists.centos.org/pipermail/centos-devel/2014-November/012370.html).

Add a custom footer
Add a custom sidebar
Clone this wiki locally