<op bin="not">Text</op> doesn't exclude bugs containing 'Text'

Definitely confirmed. ./bughelper -A -p ubiquity --format=html spits out bug 76660 and bug 64519 (for example) that should NOT match.

In Bug 76660 it's http://librarian.launchpad.net/5499606/partman that matches, not the whole bug. (So bughelper finds a VALID match).

In bug 64519 it's http://librarian.launchpad.net/4701639/partman that matches.

I'm somehow inclined to close the bug.

Can you find cases where the behaviour is really broken?

I think I found the problem, to solve this i need to have a closer look at the code of bughelper and infoFiles.py.

The search result for each element (bug text and attachments) is not saved. Only the last element (in most cases a attachment) is responsible whether a bug is shown or not.
Example:
====================================BUG: 44595
FAT32 0
res: ( True =>show) False
Traceback 3
res: ( False =>show) True
====================================BUG: 49654
FAT32 0
res: ( True =>show) False
Traceback 1
res: ( False =>show) True
FAT32 0
res: ( True =>show) False
Traceback 2
res: ( False =>show) True
FAT32 0
res: ( True =>show) False
Traceback 1
res: ( False =>show) True
FAT32 2
res: ( True =>show) True
Traceback 0
res: ( False =>show) False
FAT32 74
res: ( True =>show) True
Traceback 0
res: ( False =>show) False
http://launchpad.net/bugs/49654 [ubiquity Ubuntu: Rejected/High] - Scan Fat32 on boot
  - http://librarian.launchpad.net/3175204/partman
  - http://librarian.launchpad.net/3175208/syslog

====================================BUG: 59257

I found an example:
the added cluefile searches for all bughelper bugs without "suggestion."
In bug 79136 is "suggestion." in the first comment but not in the last attachment => this bug is shown

This should be a 0.2 block, IMHO

This needs to be discussed.

Using Henrik's clue-file and looking at Bug 76660 I get the following result:

$ ./bughelper -A -p ubiquity
...
http://launchpad.net/bugs/76660 [ubiquity Ubuntu: Rejected/Undecided] - Scan Fat32 on boot
  - http://librarian.launchpad.net/5499605/syslog
  - http://librarian.launchpad.net/5499606/partman
...

syslog and partman are listed because they don't contain "Traceback"

Maybe a output like that would be better:

$ ./bughelper -A -p ubiquity
...
http://launchpad.net/bugs/76660 [ubiquity Ubuntu: Rejected/Undecided]
  - http://librarian.launchpad.net/5499605/syslog - Scan Fat32 on boot
  - http://librarian.launchpad.net/5499606/partman - Scan Fat32 on boot
...

Markus

What part would you display behind the URL of the attachment that matches?

I think we should handle the bugreport (report + comments) and the attachments as different objects. Behind each object we should display the "<info>" of each specific matched clue.

Example:

** Cluefile **
<?xml version="1.0"?>
<clues version="0.2">
  <clue>
    <contains>
      <op>foo</op>
    </contains>
    <info>foo</info>
  </clue>
  <clue>
    <contains>
      <op>bar</op>
    </contains>
    <info>bar</info>
  </clue>
</clues>

** Bugreport **
"This bug is foo"

** Attachment no. 1 **
"here is foo"

** Attachment no. 2 **
"foo and bar"

The result should be like this:
...
http://launchpad.net/bugs/xxx [ubiquity Ubuntu: Rejected/Undecided] - foo
  - http://librarian.launchpad.net/yyy/no1 - bar
  - http://librarian.launchpad.net/zzz/no2 - foo, bar
...

Please understand this as a opinion of somebody who is not so experienced with bugtriaging :)

I'm not sure I understand what the problem is and how a fix should look like. Can somebody sum up the discussion somehow? Is this merely an output problem?

[Expired for Bug Helper because there has been no activity for 60 days.]