Free Hosting Online for WorkStations

< Previous | Contents | Next >

6.3.2. Where to File a Bug Report‌


To be able to decide where to file the bug report, you must have a good understanding of the problem and you must have identified in which piece of software the problem lies.

Ideally, you track the problem down to a file on your system and then you can use dpkg to find out which package owns that file and where that package comes from. Let’s assume that you found a bug in a graphical application. After looking at the list of running processes (the output of ps auxf), you discovered that the application was started with the /usr/bin/sparta executable:


$ dpkg -S /usr/bin/sparta

sparta: /usr/bin/sparta

$ dpkg -s sparta | grep ^Version:

Version: 1.0.1+git20150729-0kali1

$ dpkg -S /usr/bin/sparta

sparta: /usr/bin/sparta

$ dpkg -s sparta | grep ^Version:

Version: 1.0.1+git20150729-0kali1


You learn that /usr/bin/sparta is provided by the sparta package, which is in version 1.0.1+git 20150729-0kali1. The fact that the version string contains kali indicates to you that the package

comes from Kali Linux (or is modified by Kali Linux). Any package that does not have kali in its version string (or in its package name) comes straight from Debian (Debian Testing in general).


Double Check Before If you find a bug in a package imported straight from Debian, it should ideally be Filing Bugs against reported and fixed on the Debian side. However, before doing this, ensure that the Debian problem is reproducible on a plain Debian system since Kali may have caused the

problem by modifying other packages or dependencies.

The easiest way to accomplish this is to setup a virtual machine running Debian Test- ing. You can find an installation ISO for Debian Testing on the Debian Installer web- site:

https://www.debian.org/devel/debian-installer/

If you can confirm the problem in the virtual machine, then you can submit the bug to Debian by running reportbug within the virtual machine and following the instruc- tions provided.

Double Check Before If you find a bug in a package imported straight from Debian, it should ideally be Filing Bugs against reported and fixed on the Debian side. However, before doing this, ensure that the Debian problem is reproducible on a plain Debian system since Kali may have caused the

problem by modifying other packages or dependencies.

The easiest way to accomplish this is to setup a virtual machine running Debian Test- ing. You can find an installation ISO for Debian Testing on the Debian Installer web- site:

https://www.debian.org/devel/debian-installer/

If you can confirm the problem in the virtual machine, then you can submit the bug to Debian by running reportbug within the virtual machine and following the instruc- tions provided.


Most bug reports about the behavior of applications should be directed to their upstream projects except when facing an integration problem: in that case, the bug is a mistake in the way the software gets packaged and integrated into Debian or Kali. For example, if an application offers compile-time options that the package does not enable or the application does not work because of a missing library (thus putting into light a missing dependency in the package meta-information), you may be facing an integration problem. When you don’t know what kind of problem you face, it is usually best to file the issue on both sides and to cross-reference them.

Identifying the upstream project and finding where to file the bug report is usually easy. You just have to browse the upstream website, which is referenced in the Homepage field of the packaging meta-data:


$ dpkg -s sparta | grep ^Homepage:

Homepage: https://github.com/SECFORCE/sparta

$ dpkg -s sparta | grep ^Homepage:

Homepage: https://github.com/SECFORCE/sparta


Top OS Cloud Computing at OnWorks: