Skip to content

MantisBT

Jump to bottom Edit New page
Jakub Filak edited this page Feb 3, 2015 · 53 revisions

MantisBT reporter

Function of 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.

CentOS-7 reporter-mantisbt Repo 

https://copr.fedoraproject.org/coprs/mhabrnal/abrt-centos/repo/epel-7/mhabrnal-abrt-centos-epel-7.repo

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 MantisBT reporter which are related to the main reporter-bugzilla functions.

note: In 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 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, Exception in this is section Additional info. It will be stored in the Additional information field

Optional fields

It is possible to fill these following optional items:

  • Additional information - content of this field is defined in the formatting conf file
  • 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 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 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 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 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 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 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 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 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).

Implementation details

SOAP/xml libraly

There was a option to choose one of two following libraries: * csoap (libsoap) - http://csoap.sourceforge.net/ * libxml2 - http://xmlsoft.org/

csoap isn't a standard library at RHEL and Fedora and this library is built on libxml2. Libreport is already using libxml2 so for creating SOAP API request will use the library libxml2.

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