7. Oltre la pacchettizzazione

Debian è molto più di un semplice software di confezionamento e di mantenimento di questi pacchetti. Questo capitolo contiene informazioni sui modi, modi spesso molto critici, per contribuire a Debian oltre la semplice creazione e la manutenzione dei pacchetti.

Come organizzazione di volontariato, Debian si basa sulla discrezione dei suoi membri nella scelta di ciò su cui vogliono lavorare e nello scegliere la cosa più critica sulla quale trascorre la maggior parte del proprio tempo.

7.1. Segnalare i bug

Si consiglia di notificare i bug appena li si trovi nei pacchetti Debian. In realtà, gli sviluppatori Debian sono spesso la prima linea di tester. L'individuazione e la segnalazione di bug nei pacchetti di altri sviluppatori migliora la qualità di Debian.

Si leggano le istruzioni per la segnalazione di bug nel sistema di tracciamento dei bug di Debian.

Provare a presentare il bug da un account di un utente normale dove si preferisce ricevere la posta, in modo che le persone possano rintracciarvi se hanno bisogno di ulteriori informazioni sul bug. Non inviare bug come root.

È possibile utilizzare uno strumento come reportbug 1 per segnalare bug. È in grado di automatizzare e in generale facilitare il processo.

Assicurarsi che il bug non sia già stato presentato per un pacchetto. Ogni pacchetto ha una lista di bug facilmente raggiungibile a http://bugs.debian.org/nomepacchetto. Programmi di utilità come querybts 1 possono anche fornire queste informazioni (e anche reportbug di solito invocherà querybts prima di inviare).

Cercare di indirizzare i bug nella posizione corretta. Quando per esempio il proprio bug è relativo ad un pacchetto che sovrascrive i file appartenenti ad un altro pacchetto, controllare le liste di bug per entrambi questi pacchetti in modo da evitare di presentare duplicati di segnalazioni di bug.

Per maggior credito, si può passare attraverso altri pacchetti, unificando i bug che sono riportati più di una volta, o etichettando bug «fixed» quando sono già stati risolti. Si noti che quando non si è né il mittente del bug né il maintainer del pacchetto, non si dovrebbe in realtà chiudere il bug (a meno che non si ha il permesso del maintainer).

Di tanto in tanto si consiglia di controllare lo stato di avanzamento del bug che si è inviato. Cogliere l'occasione di chiudere quelli che non è possibile più riprodurre. Per scoprire tutti i bug che si sono inviati, è sufficiente visitare http://bugs.debian.org/from:proprio-indirizzo-email.

7.1.1. Riportare molti bug in una sola volta (presentazione massiccia di bug)

Segnalare un gran numero di bug per lo stesso problema su un gran numero di pacchetti differenti - vale a dire, più di 10 - è una pratica sconsigliata. Prendete tutte le misure possibili per evitare del tutto di sottoporre bug massicci. Per esempio, se il controllo per il problema può essere automatizzato, aggiungere un nuovo controllo per lintian in modo che venga emesso un errore o un avviso.

Se si riportano più di 10 bug sullo stesso argomento in una sola volta, si consiglia di inviare un messaggio a debian-devel@lists.debian.org dove descrivete la vostra intenzione prima di presentare il rapporto e di menzionarla nell'oggetto della mail. Questo permetterà ad altri sviluppatori di verificare che il bug sia un problema reale. Inoltre, aiuterà a prevenire una situazione in cui molti maintainer iniziano ad occuparsi simultaneamente dello stesso bug.

Utilizzare i programmi dd-list e se appropriato whodepends (dal pacchetto devscripts) per generare un elenco di tutti i pacchetti interessati, ed includere l'output nella propria email indirizzata a debian-devel@lists.debian.org.

Si noti che quando si inviano molti bug sullo stesso argomento, si dovrebbe inviare la segnalazione di bug a maintonly@bugs.debian.org in modo che la segnalazione non venga inoltrata alla mailing list di distribuzione bug.

The program mass-bug (from the package devscripts) can be used to file bug reports against a list of packages.

7.1.1.1. Usertag

Si potrebbe voler utilizzare le usertag BTS al momento di presentare i bug per un certo numero di pacchetti. Le usertag sono simili alle normali tag come «patch» e «wishlist», ma differiscono nel senso che sono definite dall'utente e occupano uno spazio dei nomi univoco per un particolare utente. Questo consente a più insiemi di sviluppatori di «usertaggare» lo stesso bug in diversi modi senza conflitto.

Per aggiungere usertag al momento della presentazione di bug, specificare gli pseudo-header User e Usertags:

To: submit@bugs.debian.org
Subject: title-of-bug

Package: pkgname
[ ... ]
User: email-addr
Usertags: tag-name [ tag-name ... ]

description-of-bug ...

Note that tags are separated by spaces and cannot contain underscores. If you are filing bugs for a particular group or team it is recommended that you set the User to an appropriate mailing list after describing your intention there.

Per visualizzare bug etichettati con uno specifico usertag, visitare la pagina http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=email-addr&tag=tag-name.

7.2. Costo della Quality Assurance

7.2.1. Lavoro giornaliero

Anche se c'è un gruppo dedicato di persone per la Quality Assurance, le mansioni QA non sono riservate esclusivamente a loro. È possibile partecipare a questo sforzo, mantenendo i vostri pacchetti il più possibile privi di bug e il più possibile lintian-clean (si consulti lintian). Se non si riesce a farlo, allora si dovrebbe prendere in considerazione di rendere orfani alcuni dei vostri pacchetti (si consulti Pacchetto orfano). In alternativa, si può chiedere l'aiuto di altre persone al fine di recuperare il ritardo con i bug arretrati che si hanno (si può chiedere aiuto su debian-qa@lists.debian.org o debian-devel@lists.debian.org). Allo stesso tempo, si può cercare un co-maintainer (si consulti La manutenzione collaborativa).

7.2.2. Bug squashing parties

From time to time the QA group organizes bug squashing parties to get rid of as many problems as possible. They are announced on debian-devel-announce@lists.debian.org and the announcement explains which area will be the focus of the party: usually they focus on release critical bugs but it may happen that they decide to help finish a major upgrade (like a new perl version that requires recompilation of all the binary modules).

The rules for non-maintainer uploads differ during the parties because the announcement of the party is considered prior notice for NMU. If you have packages that may be affected by the party (because they have release critical bugs for example), you should send an update to each of the corresponding bug to explain their current status and what you expect from the party. If you don't want an NMU, or if you're only interested in a patch, or if you will deal with the bug yourself, please explain that in the BTS.

People participating in the party have special rules for NMU; they can NMU without prior notice if they upload their NMU to DELAYED/3-day at least. All other NMU rules apply as usual; they should send the patch of the NMU to the BTS (to one of the open bugs fixed by the NMU, or to a new bug, tagged fixed). They should also respect any particular wishes of the maintainer.

Se non ci si sente sicuri di fare un NMU, basta inviare una patch al BTS. È molto meglio di un NMU non funzionante.

7.3. Come contattare gli altri maintainer

Durante il corso della vita all'interno di Debian, si dovranno contattare altri maintainer per vari motivi. Si vorrà discutere di un nuovo modo di cooperare tra un insieme di pacchetti correlati, o semplicemente si vorrà ricordare a qualcuno che una nuova versione è disponibile e che se ne ha bisogno.

Cercare l'indirizzo email del maintainer del pacchetto può essere fonte di distrazione. Fortunatamente, c'è un semplice alias di posta elettronica, package@packages.debian.org, che fornisce un modo per inviare email al maintainer, qualunque possa essere il loro indirizzo di posta elettronica individuale (o gli indirizzi). Sostituite package con il nome di un sorgente o un pacchetto binario.

Si potrebbe anche essere interessati a contattare le persone che sono iscritte ad un determinato pacchetto sorgente tramite The Debian Package Tracker. È possibile farlo utilizzando l'indirizzo email package@packages.qa.debian.org.

7.4. Rapportarsi con maintainer non attivi e/o non raggiungibili

If you notice that a package is lacking maintenance, you should make sure that the maintainer is active and will continue to work on their packages. It is possible that they are not active anymore, but haven't registered out of the system, so to speak. On the other hand, it is also possible that they just need a reminder.

C'è un sistema semplice (il database MIA) in cui vengono registrate informazioni inerenti i maintainer etichettati come Missing In Action. Quando un membro del gruppo QA contatta un maintainer inattivo o trova ulteriori informazioni su qualcuno, questo viene registrato nel database di MIA. Questo sistema è disponibile in /org/qa.debian.org/MIA sull'host qa.debian.org e può essere interrogato con lo strumento mia-query. Utilizzare mia-query - help per vedere come interrogare il database. Se si scopre che ancora alcuna informazione è stata registrata su un maintainer inattivo, o che è possibile aggiungere ulteriori informazioni, si

Il primo passo è quello di contattare educatamente il maintainer, ed attendere un ragionevole lasso di tempo per la risposta. È abbastanza difficile definire tempo ragionevole, ma è importante tenere in considerazione che la vita reale a volte è molto frenetica. Un modo per gestire questa situazione sarebbe quello di inviare un sollecito dopo due settimane.

A non-functional e-mail address is a violation of Debian Policy. If an e-mail "bounces", please file a bug against the package and submit this information to the MIA database.

Se il maintainer non risponde entro quattro settimane (un mese), si può supporre che la risposta probabilmente non arriverà. Se ciò accade, si dovrebbe indagare ulteriormente e cercare di raccogliere quante più informazioni utili possibili sul maintainer in questione. Ciò include:

  • Le informazioni echelon disponibili attraverso il database LDAP degli sviluppatori, che indica quando lo sviluppatore ha pubblicato l'ultimo post in una mailing list Debian. (Questo include email su aggiornamenti distribuiti tramite la lista debian-devel-changes@lists.debian.org). Inoltre, ricordare di controllare nel database se il maintainer è contrassegnato come in vacanza.

  • Il numero di pacchetti dei quali questo maintainer è responsabile e lo stato di quei pacchetti. In particolare, ci sono dei bug RC che sono stati aperti da tempo? Inoltre, quanti bug ci sono in generale? Un altro pezzo importante di informazioni è se i pacchetti sono stati NMUed e se sì, da chi.

  • C'è qualche attività del maintainer al di fuori di Debian? Ad esempio, potrebbero aver inviato qualcosa di recente a mailing list non-Debian o newsgroup.

Un po' problematici sono i pacchetti che sono stati sponsorizzatiì: il maintainer non è uno sviluppatore Debian ufficiale. Le informazioni echelon non sono disponibili per le persone sponsorizzate, per esempio, quindi è necessario trovare e contattare lo sviluppatore Debian che ha effettivamente caricato il pacchetto. Dato che hanno firmato il pacchetto, che sono responsabili per il caricamento in ogni caso, e sono probabilmente intenzionati di sapere cosa è successo alla persona che hanno sponsorizzato.

È anche consentito inviare una query a debian-devel@lists.debian.org chiedendo se qualcuno è a conoscenza del luogo in cui si trova il maintainer mancante. Si metta in Cc: la persona in questione.

Dopo aver raccolto tutto questo, è possibile contattare mia@qa.debian.org. Persone su questo alias utilizzeranno le informazioni fornite al fine di decidere come procedere. Per esempio, potrebbero rendere orfano uno o tutti i pacchetti del maintainer. Se un pacchetto è stato NMUed, potrebbero preferire di contattare la NMUer prima di rendere orfano il pacchetto; forse la persona che ha fatto la NMU è interessato al pacchetto.

Un'ultima parola: ricordare di essere educati. Si è tutti volontari e non si può dedicare tutto il proprio tempo a Debian. Inoltre, non si è a conoscenza delle circostanze della persona che è coinvolta. Forse potrebbe essere gravemente malata o potrebbe anche essere morta: non potete sapere chi potrebbe essere dall'altra parte. Si immagini come un parente si sentirà se leggesse l'email del defunto e trovasse un messaggio molto scortese, arrabbiato e accusatorio!

On the other hand, although we are volunteers, a package maintainer has made a commitment and therefore has a responsibility to maintain the package. So you can stress the importance of the greater good — if a maintainer does not have the time or interest anymore, they should let go and give the package to someone with more time and/or interest.

If you are interested in working on the MIA team, please have a look at the README file in /org/qa.debian.org/mia on qa.debian.org, where the technical details and the MIA procedures are documented, and contact mia@qa.debian.org.

7.5. Interagire con potenziali sviluppatori Debian

Il successo di Debian dipende dalla sua capacità di attrarre e trattenere nuovi e talentuosi volontari. Se si è uno sviluppatore esperto, si consiglia di partecipare al processo per coinvolgere nuovi sviluppatori. Questa sezione descrive come aiutare i nuovi potenziali sviluppatori.

7.5.1. Sponsorizzare pacchetti

Sponsoring a package means uploading a package for a maintainer who is not able to do it on their own. It's not a trivial matter; the sponsor must verify the packaging and ensure that it is of the high level of quality that Debian strives to have.

Gli sviluppatori Debian possono sponsorizzare i pacchetti. I maintainer Debian non possono.

Il processo di sponsorizzazione di un pacchetto è:

  1. The maintainer prepares a source package (.dsc) and puts it online somewhere (like on mentors.debian.net) or even better, provides a link to a public VCS repository (see salsa.debian.org: Git repositories and collaborative development platform) where the package is maintained.

  2. The sponsor downloads (or checks out) the source package.

  3. Lo sponsor esamina il pacchetto sorgente. Se trova dei problemi, informa il maintainer chiedendogli di fornire una versione corretta (il processo inizia dal punto 1).

  4. Lo sponsor non può trovare tutti i problemi che ci sono. Compila il pacchetto, lo firma e lo carica su Debian.

Before delving into the details of how to sponsor a package, you should ask yourself whether adding the proposed package is beneficial to Debian.

There's no simple rule to answer this question; it can depend on many factors: is the upstream codebase mature and not full of security holes? Are there pre-existing packages that can do the same task and how do they compare to this new package? Has the new package been requested by users and how large is the user base? How active are the upstream developers?

Ci si dovrebbe anche assicurare che il potenziale maintainer sarà un buon maintainer. Hanno già una certa esperienza con altri pacchetti? Se sì, stanno facendo un buon lavoro con loro (corretti alcuni bug)? Hanno familiarità con il pacchetto e con il suo linguaggio di programmazione? Hanno le competenze necessarie per questo pacchetto? In caso contrario, sono in grado di impararle?

It's also a good idea to know where they stand with respect to Debian: do they agree with Debian's philosophy and do they intend to join Debian? Given how easy it is to become a Debian Member, you might want to only sponsor people who plan to join. That way you know from the start that you won't have to act as a sponsor indefinitely.

7.5.1.1. Sponsorizzare un nuovo pacchetto

New maintainers usually have certain difficulties creating Debian packages — this is quite understandable. They will make mistakes. That's why sponsoring a brand new package into Debian requires a thorough review of the Debian packaging. Sometimes several iterations will be needed until the package is good enough to be uploaded to Debian. Thus being a sponsor implies being a mentor.

Non bisogna mai sponsorizzare un nuovo pacchetto senza revisionarlo. La revisione dei nuovi pacchetti realizzata da ftpmasters assicura principalmente che il software sia veramente libero. Certo, capita che inciampino sui problemi di pacchettizzazione, ma in realtà non dovrebbero. È il proprio compito garantire che il pacchetto caricato sia conforme alle Free Software Guidelines di Debian e sia di buona qualità.

La compilazione del pacchetto e il testare il software è parte della revisione, ma non è anche sufficiente. Il resto di questa sezione contiene un elenco non esaustivo dei punti da controllare nella vostra revisione. [1]

  • Verificare che il tarball originale fornito sia lo stesso che è stato distribuito dall'autore principale (quando i sorgenti sono stati ripacchettizzati per Debian, generare da soli la tarball modificata).

  • Run lintian (see lintian). It will catch many common problems. Be sure to verify that any lintian overrides set up by the maintainer are fully justified.

  • Eseguire licensecheck (parte di devscripts) e verificare che debian/copyright sia corretto e completo. Cercare i problemi di licenza (come i file con intestazioni del tipo “All rights reserved”, o con una licenza non compatibile con DFSG). grep -ri è un amico per questo compito.

  • Compilare il pacchetto con pbuilder (o qualsiasi strumento simile, vedi pbuilder) per garantire che le dipendenze di compilazione siano soddisfatte.

  • Correggere debian/control: segue le buone pratiche (si consulti Buone pratiche per debian/control)? Sono soddisfatte le dipendenze?

  • Correggere debian/rules: rispecchia le buone pratiche (si consulti Buone pratiche per debian/rules)? Vedete alcuni possibili miglioramenti?

  • Correggere gli script del maintainer (preinst, postinst, prerm, postrm, config): preinst/postrm funzioneranno quando le dipendenze non sono installate? Tutti gli script sono idempotenti (cioè si possono eseguire più volte senza conseguenze)?

  • Controllare ogni modifica ai file originali (sia in .diff.gz, o in debian/patches/ o direttamente incluse nella tarball debian dei file binari). Sono giustificate? Sono adeguatamente documentate (con DEP-3 per le patch)?

  • Per ogni file, ci si chieda perché il file è lì e se è il modo giusto per ottenere il risultato desiderato. Il maintainer sta seguendo le best practices per la pacchettizzazione (si consulti Buone pratiche per la pacchettizzazione)?

  • Build the packages, install them and try the software. Ensure that you can remove and purge the packages. Maybe test them with piuparts.

If the audit did not reveal any problems, you can build the package and upload it to Debian. Remember that even if you're not the maintainer, as a sponsor you are still responsible for what you upload to Debian. That's why you're encouraged to keep up with the package through The Debian Package Tracker.

Note that you should not need to modify the source package to put your name in the changelog or in the control file. The Maintainer field of the control file and the changelog should list the person who did the packaging, i.e. the sponsee. That way they will get all the BTS mail.

Instead, you should instruct dpkg-buildpackage to use your key for the signature. You do that with the -k option:

dpkg-buildpackage -kKEY-ID

Se si usa debuild e debsign, si può anche configurarlo in modo permanente in ~/devscripts.:

DEBSIGN_KEYID=KEY-ID

7.5.1.2. Sponsorizzare un aggiornamento di un pacchetto esistente

You will usually assume that the package has already gone through a full review. So instead of doing it again, you will carefully analyze the difference between the current version and the new version prepared by the maintainer. If you have not done the initial review yourself, you might still want to have a deeper look just in case the initial reviewer was sloppy.

To be able to analyze the difference, you need both versions. Download the current version of the source package (with apt-get source) and rebuild it (or download the current binary packages with aptitude download). Download the source package to sponsor (usually with dget).

Read the new changelog entry; it should tell you what to expect during the review. The main tool you will use is debdiff (provided by the devscripts package); you can run it with two source packages (.dsc files), or two binary packages, or two .changes files (it will then compare all the binary packages listed in the .changes).

Se si confrontano i pacchetti sorgente (esclusi i file originali nel caso di una nuova versione, ad esempio filtrando l'output di debdiff con filterdiff-i '*/debian/*'), è necessario capire tutti i cambiamenti che vedrete e che devono essere adeguatamente documentati nel changelog Debian.

If everything is fine, build the package and compare the binary packages to verify that the changes on the source package have no unexpected consequences (some files dropped by mistake, missing dependencies, etc.).

You might want to check out the Package Tracking System (see The Debian Package Tracker) to verify if the maintainer has not missed something important. Maybe there are translation updates sitting in the BTS that could have been integrated. Maybe the package has been NMUed and the maintainer forgot to integrate the changes from the NMU into their package. Maybe there's a release critical bug that they have left unhandled and that's blocking migration to testing. If you find something that they could have done (better), it's time to tell them so that they can improve for next time, and so that they have a better understanding of their responsibilities.

Se non si è trovato alcun grande problema, caricare la nuova versione. In caso contrario, chiedere al maintainer di fornire una versione corretta.

7.5.2. Granting upload permissions to DMs

After a Debian Maintainer's key has been added to the debian-maintainers keyring, a Debian Developer may grant upload permissions to the DM for specific packages by uploading a signed dak command to ftp.upload.debian.org as described in the FTP-Master's announcement to debian-devel.

This process can be simplified with the help of the dcut command from the dput-ng package. Note that this does not work with the dcut command from the dput package!

For example:

dcut dm --uid 0xfedcba9876543210 --allow nano --deny bash

If the DM's key is not in the keyring package yet but in the DD's local keyring, use the --force option and the fingerprint, without spaces and, in this special case, without the 0x prefix and in all uppercase:

dcut --force dm --uid FEDCBA9876543210FEDCBA9876543210 --allow nano

7.5.3. Promuovere nuovi sviluppatori

Consultare la pagina Promuovere nuovi sviluppatori sul sito web di Debian.

7.5.4. Gestire nuove candidature di maintainer

Consultare la Checklist per i Gestori delle Candidature sul sito web di Debian.