RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 731280 - doesn't find duplicate bugs when filing to Bugzilla
Summary: doesn't find duplicate bugs when filing to Bugzilla
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python-meh
Version: 6.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Chris Lumens
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 691780
TreeView+ depends on / blocked
 
Reported: 2011-08-17 09:06 UTC by Alexander Todorov
Modified: 2011-08-18 17:03 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-18 13:52:30 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Alexander Todorov 2011-08-17 09:06:35 UTC 
Description of problem:
Apparently the new libreport package lost the ability to search for duplicates when reporting to Bugzilla. 

Bug #731260 has been reported today at 10:53:26 EEST  then an hour later I hit the same bug and repoted it as bug #731275 at 11:48:43 EEST. 

As you can see both bugs are the same thing but libreport didn't figure that out. 

Version-Release number of selected component (if applicable):
libreport-2.0.5-5.el6.x86_64

How reproducible:
always
Comment 1 Jiri Moskovcak 2011-08-17 11:51:09 UTC 
The tracebacks are different, the crash happens on different line in different function, so it's not really a duplicate, can you try it twice with the same anaconda version?
Comment 2 Alexander Todorov 2011-08-17 14:18:26 UTC 
Above bugs are duplicates. The crash happens on the same line in the same function:

:Traceback (most recent call first):
:  File "/usr/lib/anaconda/yuminstall.py", line 1158, in simpleDBInstalled
:    mi = self.ts.ts.dbMatch('name', name)


this is where things blow up


The backtrace is a bit different at the last few lines though. One install was in gui mode and the other was text mode. However the cause of the error is in the underlying code. If you strip the last 2/3 lines you will notice that everything else is the same. This is pretty common with installer related bugs.


Can you make this request a RFE then and provide some mechanism for libreport to show the user possible duplicate bugs. I will be happy even if it told me the bug numbers which include backtrace which is 50% or more similar to mine.
Comment 3 Jiri Moskovcak 2011-08-17 16:26:51 UTC 
Such feature is being developed, please attend tech talk:
Aug 24 - ABRT - backtrace analysis server - Karel Klíč

- as for the backtrace - yes, it's the same bug, but there is not much we can do about it right now. If the calling program (in this case anaconda) doesn't provide it's own de-duplication hash the reporting library just tries to compute the hash from all information it has and it treats all data the same way (which means it doesn't care if it's (C or python or something else). In this case python-meh was used to process the exception, so I think it should provide the de-duplication hash - the libreport is meant only for reporting not for backtrace parsing/analyzing ...
Comment 4 Alexander Todorov 2011-08-18 08:26:06 UTC 
Moving to python-meh to see what other folks think.
Comment 5 Chris Lumens 2011-08-18 13:52:30 UTC 
Different tracebacks can often mean different errors.  I would like to keep it so strictly different tracebacks still result in different bugs getting filed, and we can do the duping manually if they really are the same.

python-meh does provide a hash function.  If it's not getting used, I wouldn't know why.  Since we were told to move everything to libreport, I can't follow what you guys have done anymore.
Comment 6 Jiri Moskovcak 2011-08-18 17:03:12 UTC 
(In reply to comment #5)
> 
> python-meh does provide a hash function.  If it's not getting used, I wouldn't
> know why.  Since we were told to move everything to libreport, I can't follow
> what you guys have done anymore.

- it uses the hash it if it's provided, I just wasn't sure if python-meh provides it..
Note You need to log in before you can comment on or make changes to this bug.