Translation(s): English - Italiano

(!) ?Discussion

Contents

  1. Come usare il sistema di tracciamento dei bug (BTS)
  2. Requisiti
  3. Interrogare le segnalazioni sui bug: l'interfaccia web di BTS
  4. Segnalare i bug: reportbug
  5. Modificare le segnalazioni dei bug: control@bugs.debian.org
  6. Tracciamento di versione
  7. Questions and Answers
  8. See also

Come usare il sistema di tracciamento dei bug (BTS)

Seminario online organizzato da Debian Women e tenuto su IRC da Gerfried Fuchs, 09-Dec-2010

Questa è una guida all'uso del Sistema di tracciamento dei bug (BTS, Bug Tracking System).

L'acronimo BTS sta per Bug Tracking System ed è dove Debian conserva e traccia i bug segnalati (incluse le segnalazioni delle funzionalità desiderate (wishlist), che non sono veri e propri bug). È principalmente un sistema di posta elettronica: infatti controllarlo e manipolarlo può essere fatto solamente mandando e-mail al sistema.

Requisiti

Requisiti tecnici:

Interrogare le segnalazioni sui bug: l'interfaccia web di BTS

L'interfaccia web di BTS può essere trovata all'indirizzo http://bugs.debian.org/. Attraverso questo portale si possono interrogare le segnalazioni sui bug piuttosto rapidamente (a meno che il server non sia troppo carico) ed è anche estremamente comodo.

Andando su http://bugs.debian.org/ si verrà reindirizzati ad una pagina che offre un modulo dal quale si possono eseguire delle ricerche, ma la parte più utile sono i vari reindirizzamenti che offre.

Nelle pagina panoramica ci sono tutti i gruppo principali delle segnalazioni dei bug con i link all'interno della pagina e, in fondo alla pagina, un altro modulo che aiuta a cambiare la vista per quanto riguarda diversi aspetti.

In più, si noti che sulla pagina panoramica ci sono dei caratteri piuttosto criptici dopo la descrizione breve di una segnalazione di bug. È sufficiente posizionare il mouse su di loro per ottenere un suggerimento, e si può cliccare su di loro per far aprire una finestra a comparsa contente ulteriori informazioni sul bug in questione.

Questo è un riassunto breve sull'interfaccia web. Come è stato detto, è solo una interfaccia di interrogazione. Quindi ci si può sentire liberi di cliccare in giro, esplorare completamente il sito: non può accadere nulla di male.

Segnalare i bug: reportbug

Per la segnalazione dei bug è necessario un programma di posta elettronica oppure, cosa molto più comoda, si può usare lo strumento reportbug. reportbug è principalmente uno strumento testuale (ma ci sono due interfacce grafiche: basate su urwid e GTK+), esiste anche reportbug-ng che è un'interfaccia grafica che mira a fare lo stesso lavoro, ma è comunque uno strumento differente.

Entrambi hanno bisogno di un MTA (Mail Transport Agent) in locale come postfix, exim o ssmtp. Non si entrerà nei dettagli su come devono essere configurati, in realtà è molto utile per alcuni utenti averne uno localmente in modo da poter scrivere posta elettronica sul proprio computer portatile quando non collegati e questa verrà inviata quando la connessione sarà ristabilità.

Anche quando non si dispone di un MTA locale, reportbug è ancora molto utile dato che ha l'opzione {--template}}}. Questo aiuterà a produrre informazioni per la segnalazione di bug che il manutentore del pacchetto richiederebbe in ogni caso, come le informazioni sulle dipendenze o simili.

Basta lanciare nel terminale: 

reportbug --template pacchetto

con il nome di un pacchetto che è installato. Non ci si preoccupi, non fa nulla di pericoloso, mostra solo alcune righe di testo :)

Ci sono diverse cose importanti che daranno un'idea su cosa fare, come a chi inviare le e-mail: 

To: Debian Bug Tracking System <submit@bugs.debian.org>

L'indirizzo submit@bugs è dove vengono mandate le nuove segnalazioni. Ovviamente nella segnalazione si deve inserire un titolo utile e descrittivo che dia al manutentore del pacchetto una prima idea su quale sia il problema.

Poi c'è un altro blocco che comincia con Package:, ha una riga Version: e una Severity::

I primi tre (grave, critical e serious) sono considerati critici per il rilascio e definiscono un speciale gruppo di segnalazioni. Se si è in dubbio, non usarli almeno che non si sia sicuri del loro significhato, alcune persone potrebbero reagire nervosamente se vengono utilizzati per segnalazioni che alla fine non sono tanto gravi. Si ritornerà sul significato speciale delle segnalazioni di bug critici per il rilascio più tardi.

wishlist è la gravità usata per i miglioramenti che si vorrebbero vedere in un pacchetto. Ci si prepari al fatto che alcuni manutentori di pacchetti potrebbero suggere di segnalarli direttamente agli autori originali; anche se, personalmente, l'autore di guesta guida ritiene che i manutentori di pacchetti debbano fungere da collegamento e da tramite tra gli utenti Debian e gli sviluppatori originali.

In fine, è bene ricordare che si deve cercare di essere descrittivi non solo nel titolo del bug, ma anche nel corpo della segnalazione e sarebbe fantastico se si segnalasse anche il modo per riprodurre il bug.

Per la segnalazione dei bug, c'è altra documentazione all'indirizzo http://www.debian.org/Bugs/Reporting.

Modificare le segnalazioni dei bug: control@bugs.debian.org

Per modificare le segnalazioni dei bug, c'è l'indirizzo e-mail control@bugs.debian.org. L'intero sistema di tracciamento dei bug è aperto a chiunque, così come questo indirizzo di posta elettronica. Questo significa che qualsiasi persona è tecnicamente in grado di modificare qualsiasi segnalazione di bug. L'indirizzo di controllo è dove inizia il divertimento. Funziona anche come l'indirizzo per la segnalazione per ciò che riguarda le prime righe della segnalazione.

La documentazione per questo indirizzo può essere trovata su http://www.debian.org/Bugs/server-control.

Normalmente la sintassi è: 

 comando numerobug argomenti

Il numero di argomenti varia a seconda dei comandi:

Quindi con retitle: 

retitle 12345 nuovo-titolo

si imposta il titolo della segnalazione 12345 a nuovo-titolo.

Non ci preoccupi, non può essere fatto per questo numero di segnalazione, il bug è già stato archiviato. Si possono modificare solo le segnalazioni non ancora archiviate.

Un comando usato comunemente è reassign per assegnare un bug ad un altro pacchetto. Questo comando accetta un secondo argomento dopo il nome del pacchetto: il numero di versione. Se si sa quale è la versione dell'altro pacchetto affetta dal bug è davvero utile aggiungere il numero di versione così che il tracciamento di versione possa continuare a funzionare. Il tracciamento di versione verrà spiegato in seguito, insieme ad alcuni esempi per mostrare come funzioni. :)

Il comando tag aiuta a classificare i bug. In effetti segnalando i bug si può aggiungere anche Tags: alle pseudo-intestazioni e impostare già etichette (tag) specifiche per una segnalazione.

Alcune delle etichette usate più frequentemente sono:

La lista delle etichette può essere consultata su http://www.debian.org/Bugs/Developer#tags.

I messaggi per l'indirizzo di controllo vengono archiviati nel BTS, ma non vengono inviati a nessuna destinazione particolare, perciò si può vedere che tali messaggi di controllo hanno l'intestazione Cc impostata a numerobug@bugs.debian.org. Questi messaggi vengono inviati al manutentore del pacchetto (e alle altre persone che sono iscritte all'indirizzo).

Se ci si vuole iscrivere ad una specifica segnalazione, si mandi un messaggio a numerobug-subscribe@bugs.debian.org. Si riceverà un messaggio con le istruzioni per confermare l'iscrizione, una volta fatto da quel punto in poi si riceveranno tutte le email mandate a quella segnalazione di bug. Ci si può anche iscrivere alle segnalazioni di tutti i bug di uno specifico pacchetto attraverso il PTS (Package Tracking System, sistema di tracciamento dei pacchetti) su http://packages.qa.debian.org/NOMEPACCHETTO (sostituendo a NOMEPACCHETTO il nome del pacchetto desiderato). In basso a sinistra c'è il modulo di iscrizione.

Ma se si manda una email sia a control@bugs sia a numerobug@bugs non è desiderabile confondere o disturbare lo strumento che analizza i messaggi di controllo con il testo aggiunto per il manutentore del pacchetto. Per questo motivo c'è un comando speciale thanks che forse il lettore avrà già notato dopo i comandi di controllo. Dice all'analizzatore di fermare l'analisi dell'email da quel punto in poi. Avere riguardo per l'analizzatore dei messaggi e usare "thanks" per terminare i messaggi di controllo.

Inoltre notare che è stato detto che le email mandate a numerobug@bugs vengono inviate al manutentore del pacchetto (e alle persone iscritte al bug). Queste email NON vengono mandate a chi ha segnalato i bug! Questo è un comportamento sul cui cambiamento si sta discutendo; per il momento, si deve scovare il mittente della segnalazione del bug e aggiungerlo esplicitamente ai destinatari o utilizzare un altro indirizzo di posta elettronica di comodo: numerobug-submitter@bugs.debian.org.

Tracciamento di versione

Cos'è di fatto il tracciamento di versione?

BTS tiene traccia della versione in cui è stato risolto un bug, di quali rilasci siano affetti da un bug e altre cose simili. Per questo la pseudo-intestazione Version: è molto importante nella segnalazione di un bug. Altrimenti il BTS potrebbe invece pensare che interessa tutte le versioni di un pacchetto.

Questo è il posto giusto per tornare a parlare del gruppo speciale dei bug critici per il rilascio che sono stati nominati in precedenza. Le segnalazioni di bug infatti possono venire archiviate dopo 28 giorni se soddisfano determinati criteri: di norma un bug deve essere risolto sia in unstable sia in testing per andare in archivio.

Naturalmente ciò vale solo se i bug riguardano entrambi i rilasci: una segnalazione che interessa solo unstable, ma non testing (a causa di una diversa versione) può venire archiviata immediatamente, se è stato creato un pacchetto per tutte le architetture.

Quindi la distribuzione colpita è un criterio, l'architettura è l'altro. Se entrambi i criteri solo soddisfatti, il conto alla rovescia comincia.

Le segnalazioni posso essere chiuse i molti modi. Quello più comune è il caricamento di un pacchetto che contiene una voce closes: #12345 nel changelog. Quando il pacchetto è accettato nell'archivio, viene automaticamente mandato un messaggio a 12345-done@bugs.debian.org con Version: 1.2.3 nella prima riga. Questo ovviamente può essere fatto anche a mano: si può mandare una email a numerobug-done@bugs con l'intestazione Version: che informa della chiusura del bug in quella versione.

Se la segnalazione di bug riguarda un "non problema" (come, una falsa segnalazione), l'intestazione Version: NON deve essere aggiunta al messaggio.

Questa differenza è necessaria perché il BTS deve essere in grado di distinguere i bug chiusi in una specifica versione da quelli che non sono realmente bug.

L'interfaccia web del BTS ha una funzionalità davvero molto utile per tutto questo: il grafo di versione. Lo si potrebbe già aver notato in alcune segnalazioni di bug, nell'angolo in alto a destra. Si compone di vari riquadri: quelli rotondi rossi e quelli verde quadrati. Quelle verdi sono le versioni in cui il bug è risolto, quelle rosse sono le versioni interessate.

Come già detto in precedenza, non si esiti a cliccare in giro, anche sui grafi di versione. Questo migliorerà immensamente la loro leggibilità. ;)

Example 1

Let's take a look at an easy bug graph:

[ATTACH]

This graph is really simple, there can be very complex graphs with several branches around. You see on top the green box and also the releases mentioned (testing, unstable) and below the red one (stable). On the left side you see the Severity: grave. Like mentioned, this is a release critical bug report. This is the reason why this bug report isn't archived yet.

From reading the bug report it seems to be wrongly affecting stable: icedove 3 is not part of stable, so this bug report isn't of grave severity for stable. But given that one can't set severity by release this is where the also former mentioned bug tags come into play.

There are tags for the distributions. During my work on reducing the stable release-critical bug count I stumbled upon a lot of such bug reports. So tagging this bug report with 

 tag 598274 + squeeze sid

will mark it as _not_ affect Lenny.

If a bug report has a release tag attached to it the BTS considers the bugs to only affect the given releases. If you have a local MTA and did set the DEBEMAIL environment variable like I do, there is an extremely helpful tool in the devscripts package: it's called bts - guess what it's for.

bts is a commandline client to the BTS, and I just sent a control mail about this issue with submitting this at the commandline: 

bts tag 598274 + squeeze sid  '# not relevant for stable'

So when reading further down the bug report it seems that the fixed version 0.7.3-3 was set wrongly, and we should remove it: 

bts notfound 598274 0.7.3-3

Actually such things can even be chained and combined in the bts tool, separated with dots.

This is especially useful when doing a lot of different things at once, it does only produce one email then and not several.

If you reload the bug page you will see the Tags are already set. Nothing else seem to have changed, has it? There has something changed: if you click on icedove-bidiui on the top to get to the overview page of the bugs for that package, and then click on the [G|u|☺] part in the bug short description, you will see that the bug can get archived in 28 days! Hooray, we just managed to close a stable release critical bug, live here and now :)

Example 2

Take a look at this bug:

[ATTACH]

Actually this bug looks a bit strange. The initial mail does contain a Version: header, but there is no graph at all, and no version information in the summary at the top. Let's scroll down and look what happened.

Right after the initial mail you will notice two short snippets of Bug reassigned and especially Bug No longer marked as found in versions. Ahah! It lost its version information because of a reassign! I mentioned earlier that a reassign can actually take an additional argument which is a version number. Unfortunately this hasn't been used here.

[ATTACH]

Let's check. Now that's even more funny. The bug was reassigned from open-vm-dkms to open-vm-tools. Aren't they related? If one investigates further you will find out that one is the source package name and the other is a binary built from this very source. So, actually, they should have the same version information, right? So what to do now? 

bts found 606327 2010.06.16-268169-3 '# re-add version information lost in reassign'

We will have to wait a bit for that to happen. After waiting if we reload the page, we will see that a bug graph appeared, and it contains (testing, unstable) only. The bug doesn't affect stable anymore. Second stable RC squashed! :)

Example 3

Let's check the next bugreport.

[ATTACH]

This bug graph is just a single version. The package doesn't seem to have got uploaded since Lenny was released!

So the BTS has no chance at all just by version information anyway to distinct whether this is affecting stable or not. It needs again the help of the release tags. When reading the first line of the bug report right ahead, after upgrade to squeeze, it hints in that it doesn't really affect stable.

So we are doing tagging it with + squeeze sid again. :)

After waiting a while, we see that the version graph at the bug page hasn't changed at all. That's correct, but the release tags are set, so it isn't considered affecting stable anymore. :) Third stable RC squashed!

Example 4

Now a a bit more tricky issue, these were all simple cases.

Let's see this bug report:

[ATTACH]

This bug is marked as closed since February! That's definitely longer ago than 28 days! What's going on?

We have a found version listed, and a fixed version in the information on the top left. And we have a completely red graph. Where is the green spot? Like mentioned, you can click on the graph. This doesn't give more information yet, but you can expand the graph: [Don't collapse].

[ATTACH]

Fixed in version 2.28.0-1. Can anyone find 2.28.0-1 in that graph? I don't believe that I'm that blind, and I guess you all can confirm that that version isn't in the graph. So what happened here? As can be seen the bug wasn't closed with an upload but with a plain mail.

It can easily happen that someone fumbles with the version in there, and this seems to have been the case here. Because the PTS doesn't know about that version in its history neither: http://packages.qa.debian.org/g/gnome-media.html

We just need to adjust the version information. We choose the conservative approach and mark it as fixed in 2.28.1-1 which was the next uploaded version after which it claimed to be fixed: 

bts notfound 507360 2.28.0-1 '# fixing version information' . found 507360 2.28.1-1

Similar issue with 418597, it needs also digging around the proper fixed version.

Actually there seem to be some more mishaps in the gnome-media package so I sent to one of the package maintainers a ping to go over them to take a look. :)

Those aren't RC bugs, but not closed properly neither because of version tracking.

Example 5

Now to some other issues: http://bugs.debian.org/src:logrotate. This package has a nice amount of already fixed versions. When one clicks on the bug tags for the additional tool tip information one sees that they are closed since … ages? Now what the heck? What's going on?

Let's check on 388608. The tool tip says Modified 1 year and 116 days ago. Wow! A fair time over 28 days, isn't it? ;)

Let's check the bug graph.

[ATTACH]

I doubt you will be able to read it, so click it. :) On top, (testing, unstable) in the green box. But what the? There is another unstable in a red circle further down the road?! Now can that be, two unstable versions?

Let's check packages page: http://packages.debian.org/unstable/logrotate: if you scroll down to the end of the page you find the version information. And even in here we have a colour code: green is in sync, yellow is behind in Debian revision, and red is behind in upstream version. We can safely ignore the m68k yellow because it's an "unofficial port".

The culprit version is hurd-i386, it's 3.7.1-5 and that was also the version of the circle with (stable, unstable) in the bug graph!

[ATTACH]

So what can we do? Either find a hurd porter to get the recent version of the package built, or ask one of our nice ftp masters to remove the package on hurd-i386. This is done through report bug ftp.debian.org. report bug does one guide helpfully through a menu system for this pseudo package making it extremely easy to request even such partial removals of a package.

I usually select RoQA (Request of Quality Assurance) because the QA team is everyone, including you. Yes, it consists of everyone that cares for Debian.

Actually this package has the same problem: http://bugs.debian.org/src:distcc. I did file a hurd-i386 removal request on distcc earlier today, and we have pretty quick ftp master members, it's done already.

And if you click on the information on those bugs, they will be archived soonish. :)

UDD

If you wonder how I stumbled upon the examples, I used the UDD for it.

The UDD is the Ultimate Debian Database and it can be queried with whatever comes to mind.

I did set me up two pages on my alioth account (from where everyone can query it) to track such things down: http://alioth.debian.org/~rhonda/.

The first is the list of still outstanding stable release critical bug reports (which nowadays can also be queried through http://udd.debian.org/bugs.cgi) by selecting Lenny on top. The later is just a summary of bug reports that got closed last year already and still aren't archived.

Questions and Answers

QUESTION: Is there a rule for the bug title?

ANSWER: In general no. Some package (or rather, pseudo-packages) do use the bug title for automatic processing and prefer special formatting inside. Usually those people are aware that it's not as easy to get that knowledge around so they don't get jumpy when you fail that.

One of these special (pseudo) package is ftp.debian.org. They have special requirement for the topic so they know what to do just by looking at the title of the bug report instead of going through the body, it's just additional information.

QUESTION: Who and how can change the Severity of the existing (previously reported) bug report?

ANSWER: This brings us to the next special mail address, control@bugs.debian.org

QUESTION: How important is the "APT Policy" for a bug report ?

ANSWER: Actually, I'm not exactly sure what you mean with "APT Policy" in that respect, can you explain it a bit further? It is the first time I've heard that term, especially in connection with bug reports?

Maybe the "APT policy" line, reportbug usually adds when reporting a bug to a package (summary of apt-cache policy information).

Coming back to reportbug --template output :) The actual bug report should be put in between the block with Package, Version and Severity, and the rest starting off with System Information.

The System Information block helps the maintainer to dig up troubles that might be the cause of special dependencies or debconf related settings or used kernel. When the bug report itself is very detailed, these System Information usually isn't used or needed at all. But quite often some people do submit bug reports with poor information (not intentionally) and then these System Information might give a good hint in which direction to investigate. Hope this answers your question well enough. :)

QUESTION: On output of "reportbug --template pakage-name" under system information : APT policy: (500, 'stable').

ANSWER: Yes, figured that now. This is the default value that stable users will send along. People might have other repositories set in their sources.list and tweaked the preferences so that packages from a specific release are preferred to get installed. This is apt internal information - but useful (additional to the version of the package) to the package maintainers to see in what environment the bug is happening.

QUESTION: Can you do all the control-server actions by using pseudo headers in an email to bugnumber@b.d.o or do you need to use control@b.d.o?

ANSWER: You need to use the explicit control@ mail copy, automatic parsing isn't done. From what I understood it's worked on but it might take a bit to make it reliable and not catch something it shouldn't.

QUESTION: 28 days from submission? or from last edit?

ANSWER: Answered in Tracking version Section.

QUESTION: The bug is marked as fixed in 0.7.3-3, which is also the version in stable. Why does the BTS still think it affects stable?

ANSWER: Gooood question. :) Actually I waited for that. ;) See the line right above that: It is also found in the same version. Given that a bug can't be found and fixed in the same version, the BTS is doing the conservative approach and removes both parts and considers them not existing.

QUESTION: What about bug tracking system atacks, for example aimed improper closing, reopening, etc?

ANSWER: Actually some spam messages managed to send mails to -done addresses. Those are usually easily catched, and given that everything can get reverted easily it's no that troublesome. The package maintainers usually notice those and react to them, as do the BTS admins regularly.

The BTS admins also have the possibility to block some senders from working on the bug tracking system in case they deliberately do malicious things.

But being open and inviting everyone to work on bugs totally outweights the troubles that sometimes pop up because of misuse of the control bot.

QUESTION: Shouldn't that have been (not)fixed instead of (not)found?

ANSWER: Thanks for thinking along, you are of course right. Though, I won't send another control message because actually it doesn't matter. The wrong fixed doesn't affect anything, so I leave it to not annoy the package maintainers. :)

See also