User Tools

Site Tools


X2Go Bug Tracker

The X2Go project uses debbugs as bug tracking system (BTS) software. The debbugs tracker is the software that's also used by the Debian project for tracking issues in the multitude of Debian packages.

Before X2Go had a bug tracker, the quest was: we need a BTS that is easily scriptable and a BTS that fully maps issue tracking to the developers' mail clients. Furthermore, we did not want a bug tracker that could be fed with content by clicking around on a web page.

The choice has been well thought of, you may find that there are better bug tracking systems in the world. For X2Go, we think we have found what we wanted.

Viewing Bug History

If you know either the X2Go component or the bug number you can also access the information directly:

A complete list of X2Go components with open/closed bugs can be viewed with this URL:

Reporting Bugs

How to report a bug is fully explained here. In a nutshell send a mail like the one below (everything that is written in <pointed-brackets> needs being replaced by some proper value. Please review our GDPR Notice/Privacy Policy for reporting bugs before submitting a bug report.

We strongly encourage you to subscribe to the X2Go-Dev mailing list before submitting your bug. Its subscription page is here:

Subscribing has the following advantages:

  1. Your bug report will show up on X2Go-Dev immediately, as opposed to being queued for moderation and manual inspection by a list admin (which may take a few days, as it is a volunteer task)
  2. You will receive all the relevant discussion regarding your report, even if someone forgets to CC the bug tracker in their reply

Plain bug submission

Definition of fields/formatting requirements:

Subject: <a-really-good-short-description-of-the-problem>
Package: <name-of-x2go-component>
Version: <a.b.c.d>
<one empty line - so hit [enter] twice after typing the version number>


Subject: Package contains bobcat
Package: x2goserver

When installing x2goserver on Debian stable using apt-get install x2goserver, 
instead of running the postinstall script, a bobcat is released:

    \\  //                                               ,
     \\//    ,@@@@@@@@@@,              ,@@@@@@@@,       @@@
      \ \    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@,
       \ \  (@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@<>@@@@
 --__---\ \__\@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@_@@@@@@@@@@@@o
              \@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@
    __----__  /@/@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@     -----__ U
              \@\ @@@@@@@@----__-----_   @@@@@@@@
              /@/   @@@@ @@@@@       @@@@@ @@@@@
             /@/    @@@  @@@@       @@@@@   @@@@@
            (@(     @@    @@       @@@@@     @@@@
             \@\    @@    @@        @@@@      @@@
              \/     @@@   @@@       @@@       @@@
                      @@@   @@@      @@@        @@@
                      '''   '''      '''        '''

A detailed log of the installation progress can be found at

In the description, please describe:

  1. The steps you took to produce the bug
  2. Any exact error messages
  3. What you expected to happen
  4. What actually happened

Also, please list the following info:

  1. The client machine's OS (e.g., “Windows 7 64-bit SP1” or “Ubuntu 12.04 32-bit”)
  2. The client machine's version of X2GoClient, PyHoca-GUI or Pyhoca-CLI
  3. Any relevant session settings in X2GoClient, PyHoca-GUI or Pyhoca-CLI
  4. The server's OS
  5. The server's version of the x2goserver package
  6. The server's version of the x2goserver-xsession package
  7. The server's version of the nxagent package
  8. The server's version of any other relevant packages (e.g., if the bug as about MATE integration, the version of x2gomatebindings)
  9. Any relevant settings in X2GoServer (that you changed from the defaults)

Bug submission with a Patch

In case you can provide a patch with your bug report, please attach the patch to your bug report. Do not copy+paste the patch into the mail body, as the result will not be usable!!!

Create patches for master branch and send them in git format. The documentation about creating git patches can be found here

Some of you have their own Git clones of X2Go Git. If you want to provide a patch via your public Git clone of an X2Go component, please make sure that the patch is just one commit on one of your Git branches. The rule here is simple: one Git commit on your side, one bug report in X2Go BTS. Everything else will take too much time on the patch reviewer side.

For submitting your bug report, please use this very similar template:

Subject: <a-really-good-short-description-of-the-problem>
Package: <name-of-x2go-component>
Version: <a.b.c.d>
Tag: patch


Attachment: <your-patch.diff>

Feature requests / Wishlist bugs

Feature requests are also handled via the X2Go BTS system. Feature requests are bugs with severity ,,wishlist“. See example below.

Subject: <a-really-good-short-description-of-the-problem>
Package: <name-of-x2go-component>
Version: <a.b.c.d>
Severity: wishlist


Controlling Bugs

The full control command set is documented here.

Very common control sequences are shown below.

Bug has been fixed in X2Go Git

Marking bugs being fixed in X2Go Git has been automatized.

Important notice for developers: Every X2Go source project uses /debian/changelog as (upstream!) changelog file. If you fix a bug make sure to add a »(Fixes: #<nnn>)« at the end of the changelog entry (where #<nnn> is the bug number, e.g. #186). If you commit a bug fix in that way, a script will notice that and send a mail to the bug's mail address in X2Go BTS. The bug will be tagged as »pending« and some information is added (changelog diff, link to the commit in X2Go Git's WebUI).

New version with a bug fixed has been released

As part of the X2Go release workflow, bugs that have been fixed for this release have to be closed. Normally, most bugs are already marked (tagged) as pending.

Some pending bugs, though, may only have been fixed on the master branch, but not yet on a release branch. If the release is taken from a release branch, take a look at the Fixed in: field of the bug report and check if the version to be released is mentioned in that field. If unsure, also cross-check with the X2Go component's changelog.

To: <nnn>
Cc: <nnn>
Subject: Issue resolved in <x2go-component> <version>
Control: close -1

The reported issue has been resolved in the lately release version <version> of <x2go-component>.

Thanks for reporting this issue,

Bug has been reported against the wrong X2Go Component

Even for X2Go power-users and developers it is not always easy to tell, what X2Go component causes a certain buggy behaviour in X2Go. Once a problem has been narrowed down, we might need to reassign a bug to another X2Go component.

To: <nnn>
Cc: <nnn>
Subject: <a-good-subject-line>
Control: reassign -1 <another-x2go-component>

The reported issue is actually a bug in <another-x2go-component>. Reassigning.


Thanks for reporting this issue,

Bug submitter used a non-appropriate title

People sometimes use inappropriate titles when submitting bugs. Also, the summarizing title of a bug can be improved, once we know what the reason for the occuring error really is.

To: <nnn>
Cc: <nnn>
Subject: <a-good-subject-line>
Control: retitle -1 <better-title>


Thanks for reporting this issue,

Cloning bugs

While fixing a Bug we might become aware of another issue arising in some other X2Go Component that is related to the bug we just fixed. In such a case we have to clone the bug.

To: <nnn>
Subject: <cloning-this-bug-for-a-reason>
clone #<nnn> -1
tag -1 - pending
tag -1 - patch
reassign -1 <other-x2go-component>
retitle #<nnn> <appropriate-title-for-the-new-issue>

<explain-the-new-issue-that-you-found-while-fixing #<nnn>>


GDPR Notice/Privacy Policy

This is the Privacy Policy that applies when submitting a bug report via E-Mail.


Reporting a bug means that your E-Mail address, as well as the content of your message, will immediately be visible to everyone viewing the public bug tracker of X2Go ( After subscribing to the x2go-dev mailing list (which you really should do, so the bug report is noticed by a larger audience), it will also be visible to everyone subscribed to the x2go-dev mailing list, and to everyone viewing its public archive (


Please understand that we need to keep your E-Mail address stored in our public bug tracker, so others can contact you about the bug you reported or commented on. This is a justifiable cause as set forth in Article 6 (1) b) of the GDPR

If you want to keep your real E-Mail address secret from the public, we suggest you either refrain from submitting the bug, or to submit it using a temporary, “burner” E-Mail address you created specifically for that purpose.


You have the right to withdraw your consent at any time, as per Article 7 (3) of the GDPR. If you believe an E-Mail you sent should be purged from the public bug tracker or the public archive that we operate (see the link above), please contact the list administrators at

Note that list administrators have no influence what other recipients of the particular list message do with it - e.g. if others choose to mirror contents of our list archive on their own web site, you will need to contact them separately with your deletion request.

wiki/bugs.txt · Last modified: 2018/05/24 17:19 by stefanbaur