• Table of contents
• How To Report Issues
  • First things first!
  • Best results: report from within CHIRP itself!
  • Backup procedure: Manual bug reporting
    • Effective Bug Reporting
    • Getting your debug log
      • Modern CHIRP
      • CHIRP on Windows
      • CHIRP-legacy on Linux and MacOS
    • Filing your report

How To Report Issues¶

First things first!¶

Before you file a bug, please test the latest Development Version of CHIRP to see if your issue has been fixed. These builds are generated automatically every night when there is a change, and they are available from the bottom of the download page.

Please DO NOT attach the manufacturer's software or documentation to the issue. Even if you think the file is freely available via download elsewhere, that does not mean you can legally distribute it yourself. Posting it here also opens up the CHIRP website and community to potential action by owners of those materials. If it is downloadable somewhere, feel free to post a link but DO NOT attach it to the issue.

Best results: report from within CHIRP itself!¶

If possible, it is highly recommended that you report your bug from within CHIRP itself. Doing this will help ensure that your bug report includes information about your system that we need in order to help you. To do this, go to Help -> Report or update a bug and follow the steps. Do this reporting step after you have reproduced the problem, and with the affected radio image (or CSV) file open and selected as the current tab. Even if you're experiencing a failure to download, try and let it fail, then do the reporting step.

Further updates to a given bug can be done through the same tool and help provide us all the information we need each time.

Backup procedure: Manual bug reporting¶

If you are unable to report the issue from inside CHIRP, you can follow these older bug reporting instructions. Only use this if you are unable to report from within CHIRP, or CHIRP is failing to start or work properly.

Effective Bug Reporting¶

Effective reporting of a bug or feature is critical to getting the issue resolved in a timely manner. If bug descriptions are difficult to understand or reproduce, they are less likely to receive attention. When you are crafting your bug report, try to answer the following questions:

1. What is the behavior you are seeing?
2. What is the behavior you were expecting?
3. Can you reproduce the problem all the time?
4. What are the steps required to reproduce the problem?
5. Is this specific to a certain radio model (driver) or something that you can reproduce with another radio?

In most cases, it is important to attach an image of your radio to the bug so that a developer can look at the exact state and determine what the problem is. That means the .img file that you generate by downloading from your radio and then doing File -> Save As. Note that "live mode" radios will not have a .img file, so the debug.log is all that is needed. It is often helpful describe what you expect to see in a given memory location, as well as what you actually see. If relevant or difficult to describe what you are seeing, attaching a screenshot of the behavior may also be helpful.

For more information about how to file an effective bug report, please see Eric S. Raymond's How to ask questions the smart way

Getting your debug log¶

If you are expecting something to happen (such as importing from a file, or setting a memory) and CHIRP appears to ignore the request, you probably should include your debug.log. If you are getting an error message, you should definitely include the log.

The debug log is cleared every time you start CHIRP, so the procedure for getting a usable log is:

1. Start CHIRP
2. Reproduce the failure or bug
3. Copy and send the debug log before starting CHIRP again

Modern CHIRP¶

If you are running CHIRP-next: You can access a copy of your debug log from the Help menu. Do this just after you reproduce the problem.

Here are some tips for getting the legacy CHIRP debug.log on the various platforms (or for use if CHIRP is not starting at all):

CHIRP on Windows¶

Go to Start->Run and type %APPDATA%\CHIRP (exactly as it is, including the percent signs). Your debug.log file will be in the folder that opens.

CHIRP-legacy on Linux and MacOS¶

Your debug log should be in your home directory, in .chirp/debug.log.
If you don't know how to find this, open up a terminal window.
(Mac: click on spotlight (the magnifying glass icon at top right corner), and type terminal)

Run the following command at the prompt:

cp ~/.chirp/debug.log ~/Desktop

Then close the terminal window. The debug.log file will be on your desktop.

Filing your report¶

In order to file a new bug report or feature request, you must first create (or sign into) an account. Click the Register or Sign in link at the top right of this page to do that. Once you are logged in, click the New issue link on the menu bar above to get started.

IMPORTANT: Please read the following instructions before filing an issue. Failure to include details about your problem may cause it to be closed as incomplete or ignored.

READ THIS FIRST: If you are experiencing an issue inside CHIRP, please use the Help -> Report or update a bug tool instead of filing a bug here. That tool will ensure that all the proper information is collected from your system and will maximize the likelihood that we are able to help with your issue.

Please read the following before submitting an issue here:

1. All Bug reports must include a debug log. See How to report issues for instructions. Issues opened without a debug log may be closed as non-actionable.
2. Bug reports should include an image (.img file) of the radio if you are able to get one.
3. All Bug reports must include a detailed description of what you did, what you expected, and what actually happened.
4. Please do not use issues as a place to ask usage questions. See How to get help instead.
5. Please do not file duplicate issues, and search for duplicates before you file.