1. Introduction

The aim of this HOWTO is to explain how to choose a task name and what to include in a feature request/bugreport to help Frugalware developers speed up the process of fixing a bug or fulfilling a feature request.

2. Where

The URL of our Bug tracking system is:

http://bugs.frugalware.org/

3. General

Before opening a task, use the search function, maybe there is a task for your bug/feature. In that case just add a comment such as "I can reproduce this, too." or "I would enjoy this feature, too."

There are a few topics which are often requested / reported but we have a good reason not fixing / implementing them. You can see a list of such topics in the wiki.

If you’d like to report an outdated package, first check that it isn’t listed on this site. If the package is listed please do not report it as we know there is a new version and we will update it as soon as possible.

Write bugreports in English, please. This is the only language all developers speak.

4. Bugreport

Please include the following things, unless you know what you are doing:

  1. Description of Problem - never say "does not work", quote the error message

  2. Steps to reproduce the problem

  3. Actual Results

  4. Expected Results

  5. How often does this happen?

  6. Additional Information

The default arch is i686 and the default version is -current. If these are not true, don’t forget to change them!

If you report a -current installer bug, then maybe -current is not enough, please specify the snapshot date.

If you found a security bug, then use the [SEC] prefix in the task name.

5. Feature Requests

Please don’t request more than one package in a feature request. Open a task for every package. (Of course you don’t have to open task for dependencies if they are also missing from our packages.)

If you request a package, please include:

  1. The name of the application (yes, "more games" is not enough!)

  2. The URL of the application

  3. Optionally a short note about why you think this package would be interesting for others, too

If you have a FrugalBuild for the package already, then after opening the task, upload it as an attachment. In this case, please prefix your task name with [FB], because this way it’ll be reviewed sooner.

Alternatively, you can post your FrugalBuild to the frugalware-devel mailing list for review, that can be handy if you want to submit more and more buildscripts - finally to become a developer if possible. Opening a task for your FrugalBuild is still fine if you want us to maintain it after the initial version is accepted.

Please don’t link other distribution’s buildscripts when you request a package. That information is useless for us in most cases and if you don’t include such links, you make our life easier.

5.1. Don’t request

Please don’t request custom kernels. We try to use as few patches as possible. See man kernel.sh as a reference on building your own kernel using various patchsets. Also a tutorial is available. Really, building such a kernel usually requires a buildscript of only 5 lines!

6. Pacman-g2 problems

If you get a crash from our package manager then we need a backtrace from gdb. Here are the instructions to get a backtrace:

  • Find the command line that triggers the crash. For example: pacman-g2 -Sy

  • Get the pacman-g2 git repo and compile it with debug symbols enabled: 

    $ git clone http://frugalware.org/git/pub/other/pacman-g2/pacman-g2
$ cd pacman-g2
$ sh autogen.sh
$ ./configure --enable-debug
$ make

  • Then run pacman-g2 in gdb and get the trace: 

    $ cd src/pacman-g2
$ sudo libtool gdb ./pacman-g2
> run -Sy

  • When pacman-g2 crashes, get the trace by typing bt. Here is an example: 

    Program received signal SIGSEGV, Segmentation fault.
0x0805035e in pacman_sync (targets=0x0) at sync.c:354
354             *p = 1;
(gdb) bt
#0  0x0805035e in pacman_sync (targets=0x0) at sync.c:354
#1  0x08054594 in main (argc=2, argv=0xbfee1844) at pacman.c:609

  • Attach the output of bt to your bugreport.

7. Fixed in git

Your feature request / bugreport may be closed with a "Fixed in git …" message. Git is our source control management software (just like CVS). If your task is not considered to be critical, then it will be fixed/implemented only in git, without increasing the package release. This means that it will be automatically included in the next release.