A report a maintainer can act on without writing back to ask questions is the one that gets fixed first. This page is about what such a report contains here, in ALT Linux Bugzilla.

Principles

• Be precise
• Be clear — explain it so that someone else can reproduce the bug
• One bug per report
• No bug is too trivial to report — small bugs may hide big bugs
• Clearly separate fact from speculation

Before you report

1. Bring the system up to date and try again — the bug may already be fixed:

   apt-get update && apt-get dist-upgrade

2. Search ALT Linux Bugzilla to see whether someone has reported it already. If they have, add what you know to that report rather than opening a second one.
3. Find out which package the problem belongs to. If you know the file, the package owning it is one command away:

   rpm -qf /usr/bin/whatever

   packages.altlinux.org searches by package name and by file, across every branch at once.

Reporting a New Bug

If the bug survives an update and nobody has reported it, choose "Enter a new bug". Here is what the form is asking for:

Product: the part of ALT Linux the problem belongs to. Pick it by the name the form uses, not by a shorthand: Sisyphus for the unstable branch, Branch p11 and Branch p10 for the stable ones, Regular and Simply Linux for those distributions, Infrastructure for the sites and services. The list in the form is the authority; these are only the ones most reports go to.

Component: in Sisyphus and the Branch pN products this is the source package name and nothing else — the one rpm -qf named above. In a distribution product it is an area of the system instead, a short list to pick from. There is no catch-all component here: if you cannot work out which package it is, choose the closest one and say so in the description. A maintainer who gets it by mistake will reassign it, which costs far less than a report filed nowhere.

Hardware: the form arrives with the architecture your browser reports already chosen, usually x86_64. Keep it only if the problem belongs to that architecture; if it happens everywhere, set all. The values are all, x86, x86_64, aarch64, arm, ppc, e2k, mipsel, riscv64 and loongarch64.

Severity: how much damage the problem does — not how much it annoys you. When in doubt leave it at normal.

• blocker — the worst kind, including serious security or functionality problems
• critical — the package cannot do its job
• major — worse than ordinary
• normal — ordinary, and the default
• minor — small, but still worth fixing, such as a typo in a package description or a menu entry
• enhancement — not a bug at all, but a suggestion

Those six are the whole list, spelled as the form stores them. The wiki's Bug Severity Policy writes the scale out in full, and also names a trivial level this installation does not have.

Security group: tick this if the problem is a security one and what you are about to write should not be public yet. Do not tick it out of habit: the mark can only be set while the report is being opened, only members of the group can remove it afterwards, and a marked report is visible only to people who are in every group it is marked for.

Summary: one sentence that says what is broken. This is what everyone else will read in search results, so make it specific.

Good: "gpg2 --card-status fails with SCDaemon has no card after a Yubikey is reinserted"
Bad: "program crashes"
Bad: "does not work"

Description: everything a maintainer needs in order to see the problem on their own machine:

• the distribution name and version, and when you last updated;
• the version of the package, from rpm -q <package>;
• Steps to reproduce: numbered, short, and complete. Include whatever is unusual about your installation and configuration;
• Actual result: what happened when you followed those steps;
• Expected result: what should have happened instead. Write this down even when it seems obvious — it is often the line that turns out to be the disagreement;
• logs. For a kernel problem, dmesg. For a service, the output of journalctl -u <service>;
• for anything touching hardware, lspci -nn and lsusb -v;
• whether it also happens on another version or another branch, if you have one to try.

Long logs and screenshots belong in attachments rather than in the description — add them once the report exists.

One report per problem

Several problems that look related still go in separate reports, one each, even when they live in the same package. A single report covering several problems has no state of its own: it cannot be closed while any part of it is open, and the parts drift apart as they are answered.

When a group of reports does belong together, tie them up in a metabug — a report that depends on each of them, carries the keyword METABUG and [META] in its summary, and whose description says only what the group as a whole is for. Discussion of the individual problems stays in the individual reports.

After you send it

The maintainer of the package is notified by mail. Anyone can add comments and attach files — a patch, a log, an example. The maintainer changes the state as the work goes, or reassigns the report to someone else. If the problem comes back in a later version, reopen the report rather than filing a new one.

You will be mailed about anything that happens to a report you opened or are subscribed to. Use CC to add people who should know about it — the package changelog and its ACL say who those are — in the form login@altlinux.org. If you cannot confirm that an address has an account here, leave it out and add it once the report exists: an address ALT Linux Bugzilla does not know fails the whole submission, and the text you wrote goes down with it. What arrives by mail is yours to configure in your preferences.

The longer version

The wiki carries a fuller walk-through, including searching, closing reports and deciding whether to reopen one: ALT Linux Bugzilla mini-HOWTO.