Writing clue files

As described in the introductory documentation you can create simple cluefiles bugxml -a. For more complex search criteria you need to edit the XML files as described here.

The basic clue file created with bugxml has this header:

<?xml version="1.0"?>
<clues version="0.1">

and contains a single clue on the form:

  <clue>
    <contains>
      <op>crash</op>
    </contains>
    <info>A CRASHER BUG</info>
  </clue>

and finally closes with:

{{{</clues> }}}

You can add a long list of clues with the <clues> </clues> tag, each with a list of search strings within <op> </op> tags. Each clue also requires an <info> tag to hold a brief description of the bug type. Uf the clue vdescribes a duplicate then this description would typically be the title of the original bug.

Optional elements

Clues can be inherited from other clue files. totem can for example inherit clues from gnome and gstreamer:

    <inherits>
        <inherit>gnome</inherit>
        <inherit>gstreamer</inherit>
    </inherits>

You can also use the logical opperators AND, OR and NOT to create detailed bug searches. Example:

            <and>
                <or>
                        <op>text</op>
                        <op bin="not">text2</op>
                </or>
                <op>text3</op>
            </and>

Example

packages/ubiquity.info:

<clues>
    <clue>
        <contains>
            <op>Failed to unmount /var/lib/ubiquity/source</op>
        </contains>
        <info>This might be something that Henrik knows more about</info>
    </clue>
    <clue>
        <contains>
            <op>IOError: [Errno 28] No space left on device</op>
        </contains>
        <info>This bug can be rejected as it was the user's fault.</info>
    </clue>
    <clue>
        <contains>
            <op>ubiquity: ['/bin/hw-detect'] exited with code 1</op>
        </contains>
        <info>This can be probably reassigned to another package.</info>
    </clue>
    <clue>
        <contains>
            <op>['/usr/lib/ubiquity/localechooser/prebaseconfig'] exited with code 1</op>
        </contains>
        <info>This might be something that Henrik knows more about.</info>
    </clue>
    <clue>
        <contains>
            <op>UnicodeDecodeError: 'utf8' codec can't decode bytes in position</op>
        </contains>
        <info>This might be something that Henrik knows more about</info>
    </clue>
    <clue>
        <contains>
            <op>AttributeError: 'NoneType' object has no attribute 'stdin'</op>
        </contains>
        <info>This might be something that Henrik knows more about</info>
    </clue>
    <clue>
        <contains>
            <op>/usr/lib/python2.4/site-packages/debconf.py</op>
        </contains>
        <info>This might be something that Henrik knows more about</info>
    </clue>
    <clue>
        <contains>
            <op>OSError</op>
        </contains>
        <info>This might be something that Henrik knows more about</info>
    </clue>
</clues>

Declare duplicate numbers

If you add a clue that basically points out, that bug A (which contains a certain condition) is a duplicate of bug B, you probably don't want bughelper to list 'B' every time, you run that query. Therefore you can do the following

./bugxml -a totem "XRHFAOJAH.so" "This is a duplicate of Bug 13466." -d 13466

Sharing clue files

zthe real benefits of bughelper become apparent when bug triagers and developers share their knowledge of the through common clue files.

To start sharing clue files you must first check out the latest a copy of the shared repository as a local bzr branch:

bzr checkout sftp://YOUR-LAUNCHPAD-ID@bazaar.launchpad.net/~bugsquad/bughelper-data/main bughelper-data

This is actually the same repository that bughelper updates its cluefiles from normally, but with this format you can make changes and upload them again with bzr.

Simply edit the .info for a gien package, commit the changes with

 bzr commit -m "added a totem clue"

and push the changes back up to the shared repository with:

{{{??? }}}

Optionally, you can edit the Local-Packages-Dir: line of ~/.bughelper/config` to contain the path to the bughelper-data bzr directory. This will alow you to work directly with the shared repository and stay in sync.

Go back to [:BugHelper/Documentation].BR CategoryBugSquad