1.4. La prima segnalazione

Adesso, reportbug ci chiede il nome del pacchetto obbiettivo della nostra segnalazione, e noi scriviamo quello che abbiamo scelto al prompt di comando:

> openclipart.openoffice.org 

E il programma fa delle magie:

*** Welcome to reportbug.  Use ? for help at prompts. ***
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'mio-nome <mio-nome@mio.provider>' as your from 
address.
Getting status for openclipart.openoffice.org...
No matching source or binary packages. 
A package named "openclipart.openoffice.org" does not appear to be 
installed; do you want to search for a similar-looking filename in an 
installed package [Y|n|q|?]? 

Semplicemente, ricerca e verifica la versione del pacchetto che risulta installata sulla macchina confrontandola con nuove versioni eventualmente presenti sui repository Debian, e nel mio caso mi segnala subito qualcosa di strano: Purtroppo preso dalla foga del neofita, io non ho letto attentamente il messaggio, non lo ho compreso bene, e ho scelto "n" per "no" come opzione, la qual cosa mi ha permesso di proseguire ugualmente con la segnalazione: ma poco più avanti vedremo come ho fatto a correggere l'errore.

Getting available info for openclipart.openoffice.org...
Please enter the version of the package this report applies to 
(blank OK)> 

Ancora, va alla ricerca di informazioni riguardanti il pacchetto incriminato, e non trovandone a causa del mio errore, mi chiede di inserire la versione alla quale si fa riferimento; inserisco quella che so darmi il problema:

> 0.18+dfsg-8

Bene, il mio errore è stato quello di scrivere come nome di pacchetto "openclipart.openoffice.org" anzichè il corretto "openclipart-openoffice.org".

Ma comunque procediamo e vediamo cosa propone ora reportbug:

Will send report to Debian (per lsb_release). 
Querying Debian BTS for reports on openclipart.openoffice.org 
(source)...
No bug reports found. 

Please briefly describe your problem (max. 100 characters allowed; you 
can elaborate in a moment; an empty response will stop reportbug). This 
will be the bug email subject, so write a concise summary of what is 
wrong with the package, for example, "fails to send email" or "does not 
start with -q option specified." 

Qui ci comunica alcune cose molto interessanti ed importanti:

Vedremo poi cosa occorre fare se il risultato della ricerca nell'archivio del BTS Debian avesse segnalato la presenza di altri bug per il nostro pacchetto obbiettivo.

Bisogna assolutamente evitare un errore molto comune che è quello di iniziare l'intestazione con il nome del pacchetto, tipo "reportbug: bla bla bla..."; infatti, siccome quel nome viene aggiunto comunque in maniera automatica dal programma reportbug, il risultato sarebbe "reportbug: reportbug: bla bla bla...". Io NON ho fatto questo errore perchè prima di iniziare mi sono guardato l'Howto di Wolfgang Loien, ma ammetto che mi sarebbe venuto molto naturale iniziare la segnalazione con il nome del pacchetto cui si riferiva.

Per farsi un'idea di come scrivere una corretta intestazione, piena di significato, conviene dare un'occhiata agli esempi presenti sul BTS Debian e magari scritti da persone molto più esperte di noi: teniamo bene presente che questa è la prima cosa che il manutentore vedrà, e spesso, l'unica riga che guarderanno tutti gli altri. Pertanto per evitare report scadenti, occorre impegnarsi e provare se si può, a redigerne una di qualità.

Logicamente, essendo il BTS internazionale, questa intestazione, come la descrizione successiva del bug stesso vanno scritte in lingua inglese. Qualcuno potrebbe obiettare del perchè e io trovarmi daccordo con lui, ma torneremmo ai discorsi "filosofici" che esulano dal compito che ci siamo qui prefissi.

Io non ho fatto molta fatica a scegliere una intestazione chiara:

> remove Openoffice.org (and vice-versa)

Confermo con "Invio" e la schermata successiva è questa (anche lei molto interessante):

Rewriting subject to 'openclipart.openoffice.org: remove Openoffice.org 
(and vice-versa)' 
How would you rate the severity of this problem or report? 

1 critical        makes unrelated software on the system (or the whole 
                  system) break, or causes serious data loss, or 
                  introduces a security hole on systems where you 
                  install the package.
2 grave           makes the package in question unusable by most or all 
                  users, or causes data loss, or introduces a security 
                  hole allowing access to the accounts of users who use 
                  the package.
3 serious         is a severe violation of Debian policy (that is, the 
                  problem is a violation of a 'must' or 'required' 
                  directive); may or may not affect the usability of the
                  package. Note that non-severe policy violations may be
                  'normal,' 'minor,' or 'wishlist' bugs. (Package 
                  maintainers may also designate other bugs as 'serious'
                  and thus release-critical; however, end users should 
                  not do so.)
4 important       a bug which has a major effect on the usability of a 
                  package, without rendering it completely unusable to 
                  everyone.
5 does-not-build  a bug that stops the package from being built from 
                  source. (This is a 'virtual severity'.)
6 normal          a bug that does not undermine the usability of the 
                  whole package; for example, a problem with a 
                  particular option or menu item.
7 minor           things like spelling mistakes and other minor cosmetic 
                  errors that do not affect the core functionality of 
                  the package.
8 wishlist        suggestions and requests for new features.

Please select a severity level: [normal] 

Non è ovviamente il mio caso per cui accetto il valore predefinito "normal", premo "Invio" e procedo.