5. Gestione dei pacchetti

Questo capitolo contiene informazioni relative alla creazione, al caricamento, al mantenimento, ed al porting dei pacchetti.

5.1. Nuovi pacchetti

Se si desidera creare un nuovo pacchetto per la distribuzione Debian, si dovrebbe verificare prima l'elenco Work-Needing and Prospective Packages (WNPP). Il controllo dell'elenco WNPP assicura che nessuno stia già lavorando sulla pacchettizzazione del software, e che lo sforzo non sia duplicato. Si leggano le pagine web WNPP per ulteriori informazioni.

Supponendo che nessun altro stia già lavorando sul proprio futuro pacchetto, è necessario poi presentare una segnalazione di bug (Segnalare i bug) nei confronti dello pseudo-pacchetto wnpp descrivendo come si vuole procedere per creare un nuovo pacchetto, includendo, senza limitarsi ad essa, una descrizione del medesimo, la licenza del futuro pacchetto, e l'URL corrente da dove è possibile scaricarlo.

You should set the subject of the bug to ITP: foo -- short description, substituting the name of the new package for foo. The severity of the bug report must be set to wishlist. Please send a copy to debian-devel@lists.debian.org by using the X-Debbugs-CC header (don't use CC:, because that way the message's subject won't indicate the bug number). If you are packaging so many new packages (>10) that notifying the mailing list in separate messages is too disruptive, send a summary after filing the bugs to the debian-devel list instead. This will inform the other developers about upcoming packages and will allow a review of your description and package name.

Inserire una voce Closes: #nnnnn nel changelog del nuovo pacchetto per la segnalare di bug da chiudere automaticamente una volta che il nuovo pacchetto è installato in archivio (si consulti Quando i bug vengono chiusi da nuovi upload).

Se si pensa che il proprio pacchetto abbia bisogno di alcune spiegazioni per gli amministratori della coda NEW dei pacchetti, includerle nel proprio changelog, inviare a ftpmaster@debian.org una risposta alla email ricevuta come maintainer dopo il proprio caricamento, o rispondere alla email di rifiuto in caso si stia già effettuando nuovamente il caricamento.

Nel chiudere i bug di sicurezza includete i numeri CVE come Closes: #nnnnn. Questo è utile al il team di sicurezza per monitorare le vulnerabilità. Se un caricamento è fatto per risolvere il bug prima che l'ID della segnalazione fosse noto, è buona norma aggiornare la voce storica del changelog con il successivo caricamento. Anche in questo caso, Includere tutti i puntatori alle informazioni di fondo nella voce originale del changelog.

Ci sono una serie di motivi per cui chiediamo ai maintainer di dichiarare le loro intenzioni:

• Aiuta il maintainer (potenzialmente nuovo) ad attingere all'esperienza di persone sulla lista, e permette loro di sapere se qualcun altro sta già lavorando su di esso.

• Esso consente ad altre persone di pensare se lavorare sul pacchetto sapendo che c'è già un volontario, così gli sforzi possono essere condivisi.

• Consente al resto dei maintainer di sapere di più sul pacchetto rispetto alla riga di descrizione e alla solita voce del changelog «Initial release» che viene inviata alla debian-devel-changes@lists.debian.org.

• È utile per le persone che vivono fuori unstable (e che formano la nostra prima linea di tester). Dovremmo incoraggiare queste persone.

• Gli annunci danno ai maintainer e ad altre parti interessate una migliore sensazione di ciò che sta accadendo, e cosa c'è di nuovo, nel progetto.

Consultare http://ftp-master.debian.org/REJECT-FAQ.html sui comuni motivi di rifiuto per un nuovo pacchetto.

5.2. Registrare i cambiamenti nel pacchetto

Changes that you make to the package need to be recorded in the debian/changelog file, for human users to read and comprehend. These changes should provide a concise description of what was changed, why (if it's in doubt), and note if any bugs were closed. They also record when the packaging was completed. This file will be installed in /usr/share/doc/package/changelog.Debian.gz, or /usr/share/doc/package/changelog.gz for native packages.

Il debian/changelog si adegua ad una certa struttura, con una serie di campi differenti. Un campo di nota, la distribuzione, è descritto in Scegliere una distribuzione. Maggiori informazioni sulla struttura di questo file si trovano nella sezione della Debian Policy intitolata debian/changelog.

Le voci del changelog possono essere usate per chiudere automaticamente i bug Debian quando il pacchetto viene installato nell'archivio. Si consulti Quando i bug vengono chiusi da nuovi upload.

È convenzione che la voce del changelog di un pacchetto che contiene una nuova versione originale del software è la seguente:

* New upstream release.

Ci sono strumenti che consentono di creare voci e di finalizzare il changelog per la stampa - si consulti devscripts e dpkg-dev-el.

Si consulti anche Buone pratiche per il debian/changelog.

5.3. Testare del pacchetto

Prima di caricare il proprio pacchetto, si dovrebbe fare dei test di base su di esso. Come minimo, si dovrebbe provare le seguenti attività (è necessario avere una versione precedente dello stesso pacchetto Debian in giro):

• Run lintian over the package. You can run lintian as follows: lintian -v package-version.changes. This will check the source package as well as the binary package. If you don't understand the output that lintian generates, try adding the -i switch, which will cause lintian to output a very verbose description of the problem.

  Normalmente, un pacchetto non dovrebbe essere caricato se provoca a lintian di emettere errori (inizieranno con E).

  Per maggiori informazioni su lintian, si consulti lintian.

• Facoltativamente eseguite debdiff (si consulti debdiff) per analizzare i cambiamenti da una versione precedente, se ne esiste una.

• Install the package and make sure the software works in an up-to-date unstable system.

• Upgrade the package from an older version to your new version.

• Rimuovete il pacchetto, quindi reinstallarlo.

• Installing, upgrading and removal of packages can either be tested manually or by using the piuparts tool.

• Copiare il pacchetto sorgente in una cartella diversa e provare a spacchettarlo ed a ricompilarlo. Questo testa se il pacchetto si basa su file esistenti al di fuori di esso, o se si basa su permessi che sono stati conservati sui file distribuiti all'interno del .diff.gz.

5.4. Struttura del pacchetto sorgente

Ci sono due tipi di pacchetto sorgente Debian:

• i cosiddetti pacchetti nativi, dove non c'è distinzione tra i sorgenti originali e le patch applicate per Debian

• i (più comuni) pacchetti dove c'è un file di archivio dei sorgenti originali accompagnato da un altro file che contiene le modifiche apportate da Debian

Per i pacchetti nativi, il pacchetto sorgente include un file di controllo del codice sorgente Debian (.dsc) e l'archivio dei sorgenti (.tar.{gz,bz2,xz}). Un pacchetto sorgente di un pacchetto non nativo include un file Debian di controllo sorgenti, l'archivio dei sorgenti originali (.orig.tar.{gz,bz2,xz}) e le modifiche Debian (.diff.gz per il formato sorgente «1.0» o .debian.tar.{gz,bz2,xz} per il formato sorgente «3.0 (quilt)»).

Con il formato dei sorgenti «1.0», se un pacchetto è nativo o non è stato determinato da dpkg-source al momento della compilazione. Al giorno d'oggi, si raccomanda di essere espliciti sul formato sorgente desiderato mettendo entrambi «3.0 (quilt)» o «3.0 (nativo)» in debian/source/format. Il resto di questa sezione riguarda solo i pacchetti non-nativi.

The first time a version is uploaded that corresponds to a particular upstream version, the original source tar file must be uploaded and included in the .changes file. Subsequently, this very same tar file should be used to build the new diffs and .dsc files, and will not need to be re-uploaded.

Per impostazione predefinita, dpkg-genchanges e dpkg-buildpackage includerà il file tar dei sorgenti originali, se e solo se l'attuale voce del changelog ha una versione originale diversa dalla voce precedente. Questo comportamento può essere modificato utilizzando -sa per includere sempre o -sd per lasciarlo sempre fuori.

Se nessun sorgente originale è incluso nel caricamento, il file tar dei sorgenti originali utilizzato da dpkg-source quando fu costruito il file .dsc e diff da caricare deve essere del tutto identico a quello già presente in archivio.

Please notice that, in non-native packages, permissions on files that are not present in the *.orig.tar.{gz,bz2,xz} will not be preserved, as diff does not store file permissions in the patch. However, when using source format “3.0 (quilt)”, permissions of files inside the debian directory are preserved since they are stored in a tar archive.

5.5. Scegliere una distribuzione

Ogni caricamento deve specificare a quale distribuzione il pacchetto è destinato. Il processo di compilazione del pacchetto estrae questa informazione dalla prima riga del debian/changelog e la inserisce nel campo Distribution del file .changes.

I pacchetti sono generalmente caricati in unstable. I caricamenti in unstable o experimental dovrebbero utilizzare questi nomi nelle voci del changelog; caricamenti per altre suite dovrebbero utlizzare il nome della suite, in modo da evitare ambiguità.

In realtà, ci sono altre due possibili distribuzioni: stable-security e testing-security, ma si legga Gestione di bug relativi alla sicurezza per ulteriori informazioni su queste ultime.

Non è possibile caricare un pacchetto in più distribuzioni contemporaneamente.

5.5.1. Caso particolare: caricamenti sulle distribuzioni stable e oldstable

Uploading to stable means that the package will be transferred to the proposed-updates-new queue for review by the stable release managers, and if approved will be installed in the stable-proposed-updates directory of the Debian archive. From there, it will be included in stable with the next point release.

Uploads to a supported stable release should target their suite name in the changelog, i.e. bookworm or bullseye. You should normally use reportbug and the release.debian.org pseudo-package to send a source debdiff, rationale and associated bug numbers to the stable release managers, and await a request to upload or further information.

If you are confident that the upload will be accepted without changes, please feel free to upload at the same time as filing the release.debian.org bug. However if you are new to the process, we would recommend getting approval before uploading so you get a chance to see if your expectations align with ours.

Either way, there must be an accompanying bug for tracking, and your upload must comply with these acceptance criteria defined by the the stable release managers. These criteria are designed to help the process be as smooth and frustration-free as possible.

• The bug you want to fix in stable must be fixed in unstable already (and not waiting in NEW or the delayed queue).

• The bug should be of severity "important" or higher.

• Bug meta-data - particularly affected versions - must be up to date.

• Fixes must be minimal and relevant and include a sufficiently detailed changelog entry.

• A source debdiff of the proposed change must be included in your request (not just the raw patches or "a debdiff can be found at $URL").

• The proposed package must have a correct version number (e.g. ...+deb12u1 for bookworm or +deb11u1 for bullseye) and you should be able to explain what testing it has had. See the Debian Policy for the version number: https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-version-conventions

• The update must be built in an stable environment or chroot (or oldstable if you target that).

• Fixes for security issues should be co-ordinated with the security team, unless they have explicitly stated that they will not issue an DSA for the bug (e.g. via a "no-dsa" marker in the Debian Security Tracker).

• Do not close release.debian.org bugs in debian/changelog. They will be closed by the release team once the package has reached the respective point release.

It is recommended to use reportbug as it eases the creation of bugs with correct meta-data. The release team makes extensive use of usertags to sort and manage requests and incorrectly tagged reports may take longer to be noticed and processed.

caricamenti su distribuzioni oldstable sono possibili a patto che non siano state archiviate. Valgono le stesse regole per stable.

In the past, uploads to stable were used to address security problems as well. However, this practice is deprecated, as uploads used for Debian security advisories (DSA) are automatically copied to the appropriate proposed-updates archive when the advisory is released. See Gestione di bug relativi alla sicurezza for detailed information on handling security problems. If the security team deems the problem to be too benign to be fixed through a DSA, the stable release managers are usually willing to include your fix nonetheless in a regular upload to stable.

5.5.2. Special case: the stable-updates suite

Sometimes the stable release managers will decide that an update to stable should be made available to users sooner than the next scheduled point release. In such cases, they can copy the update to the stable-updates suite, use of which is enabled by the installer by default.

Initially, the process described in Caso particolare: caricamenti sulle distribuzioni stable e oldstable. should be followed as usual. If you think that the upload should be released via stable-updates, mention this in your request. Examples of circumstances in which the upload may qualify for such treatment are:

• The update is urgent and not of a security nature. Security updates will continue to be pushed through the security archive. Examples include packages broken by the flow of time (c.f. spamassassin and the year 2010 problem) and fixes for bugs introduced by point releases.

• The package in question is a data package and the data must be updated in a timely manner (e.g. tzdata).

• Fixes to leaf packages that were broken by external changes (e.g. video downloading tools and tor).

• Packages that need to be current to be useful (e.g. clamav).

• Uploads to stable-updates should target their suite name in the changelog as usual, e.g. bookworm.

Once the upload has been accepted to proposed-updates and is ready for release, the stable release managers will then copy it to the stable-updates suite and issue a Stable Update Announcement (SUA) via the debian-stable-announce mailing list.

Any updates released via stable-updates will be included in stable with the next point release as usual.

5.5.3. Caso particolare: caricamenti su testing/testing-proposed-updates

Consultare le informazioni nella Aggiornamenti diretti di testing per i dettagli.

5.6. Caricare un pacchetto

5.6.1. Source and binary uploads

Each upload to Debian consists of a signed .changes file describing the requested change to the archive, plus the source and binary package files that are referenced by the .changes file.

If possible, the version of a package that is uploaded should be a source-only changes file. These are typically named *_source.changes, and reference the source package, but no binary .deb or .udeb packages. All of the corresponding architecture-dependent and architecture-independent binary packages, for all architectures, will be built automatically by the build daemons in a controlled and predictable environment (see wanna-build for more details). However, there are several situations where this is not possible.

The first upload of a new source package (see Nuovi pacchetti) must include binary packages, so that they can be reviewed by the archive administrators before they are added to Debian.

If new binary packages are added to an existing source package, then the first upload that lists the new binary packages in debian/control must include binary packages, again so that they can be reviewed by the archive administrators before they are added to Debian. It is preferred for these uploads to be done via the experimental suite.

Uploads that will be held for review in other queues, such as packages being added to the *-backports suites, might also require inclusion of binary packages.

The build daemons will automatically attempt to build any main or contrib package for which the build-dependencies are available. Packages in non-free and non-free-firmware will not be built by the build daemons unless the package has been marked as suitable for auto-building (see Marcare i pacchetti non-free come compilabili automaticamente).

The build daemons only install build-dependencies from the main archive area. This means that if a source package has build-dependencies that are in the contrib, non-free or non-free-firmware archive areas, then uploads of that package need to include prebuilt binary packages for every architecture that will be supported. By definition this can only be the case for source packages that are themselves in the contrib, non-free or non-free-firmware archive areas.

Bootstrapping a new architecture, or a new version of a package with circular dependencies (such as a self-hosting compiler), will sometimes also require an upload that includes binary packages.

Binary packages in the main archive area that were not built by Debian's official build daemons will not usually be allowed to migrate from unstable to testing, so an upload that contains binary packages built by the package's maintainer must usually be followed by a source-only upload after the binary upload has been accepted. This restriction does not apply to contrib, non-free or non-free-firmware packages.

5.6.2. Caricamento su ftp-master

To upload a package, you should upload the files (including the signed changes and dsc file) with anonymous ftp to ftp.upload.debian.org in the directory /pub/UploadQueue/. To get the files processed there, they need to be signed with a key in the Debian Developers keyring or the Debian Maintainers keyring (see https://wiki.debian.org/DebianMaintainer).

Notare che è necessario trasferire il file delle modifiche alla fine. In caso contrario, il caricamento potrebbe essere respinto in quanto il software di mantenimento analizzerà il file delle modifiche e noterà che non tutti i file sono stati caricati.

È inoltre possibile trovare i pacchetti Debian dupload o dput utili quando si caricano i pacchetti. Questi comodi programmi aiutano ad automatizzare il processo di caricamento dei pacchetti in Debian.

For removing packages or cancelling an upload, please see ftp://ftp.upload.debian.org/pub/UploadQueue/README and the Debian package dcut.

Finally, you should think about the status of your package with relation to testing before uploading to unstable. If you have a version in unstable waiting to migrate then it is generally a good idea to let it migrate before uploading another new version. You should also check the The Debian Package Tracker for transition warnings to avoid making uploads that disrupt ongoing transitions.

5.6.3. Caricamenti differiti

A volte è utile caricare immediatamente un pacchetto, ma si desidera che quest'ultimo arrivi nell'archivio solo dopo qualche giorno. Ad esempio, quando si prepara un Caricamenti dei Non-Maintainer (NMU), si potrebbe desiderare di dare al maintainer qualche giorno per reagire.

Un caricamento nella cartella differita fa mantenere il pacchetto nella coda caricamenti differiti. Quando il tempo di attesa specificato è terminato, il pacchetto viene spostato nella cartella regolare incoming per l'elaborazione. Questo viene fatto attraverso il caricamento di ftp.upload.debian.org nella cartella di caricamentoDELAYED/X-day (X tra 0 e 15). 0-day viene caricato più volte al giorno in ftp.upload.debian.org.

With dput, you can use the --delayed DELAY parameter to put the package into one of the queues.

5.6.4. Caricamenti di sicurezza

Do NOT upload a package to the security upload queue (on *.security.upload.debian.org) without prior authorization from the security team. If the package does not exactly meet the team's requirements, it will cause many problems and delays in dealing with the unwanted upload. For details, please see Gestione di bug relativi alla sicurezza.

5.6.5. Altre code di caricamento

Vi è una coda di caricamento alternativa in Europa a ftp://ftp.eu.upload.debian.org/pub/UploadQueue/. Funziona allo stesso modo come ftp.upload.debian.org, ma dovrebbe essere più veloce per gli sviluppatori europei.

I pacchetti possono anche essere caricati via ssh al ssh.upload.debian.org; i file devono essere messi in /srv/upload.debian.org/UploadQueue. Questa coda non supporta Caricamenti differiti.

5.6.6. Notifications

I maintainer dell'archivio Debian sono responsabili per la gestione dei caricamenti dei pacchetti. Per la maggior parte, i caricamenti sono gestiti automaticamente su base giornaliera dagli strumenti di manutenzione, dak process-upload. In particolare, aggiornamenti di pacchetti esistenti nella distribuzione unstable sono gestiti automaticamente. In altri casi, in particolare per i nuovi pacchetti, il posizionamento del pacchetto caricato nella distribuzione viene gestita manualmente. Quando i caricamenti sono gestiti manualmente, la modifica all'archivio può richiedere un certo tempo. Si sia pazienti.

In ogni caso, si riceverà una email di notifica per indicare che il pacchetto è stato aggiunto all'archivio, inoltre indica quali bug saranno chiusi dal caricamento. Esaminare attentamente questa notifica, controllando se qualche bug che si intendeva chiudere è stato tralasciato.

La notifica di installazione include anche informazioni sulla sezione nella quale il pacchetto è stato inserito. Se vi è una disparità, riceverai una email separata di notifica che te lo comunicherà. Si continui a leggere di seguito.

Si noti che se si carica tramite le code, il software demone delle code invierà anche una notifica via email.

Also note that new uploads are announced on the Canali IRC channel #debian-devel-changes. If your upload fails silently, it could be that your package is improperly signed, in which case you can find more explanations on ssh.upload.debian.org:/srv/upload.debian.org/queued/run/log.

5.7. Specificare la sezione del pacchetto, sottosezione e la priorità

I campi Section e Priority del file debian/control in realtà non specificano dove il file verrà inserito nell'archivio, né la sua priorità. Al fine di mantenere l'integrità complessiva dell'archivio, sono i maintainer dell'archivio che hanno il controllo su questi campi. I valori del file debian/control sono in realtà solo suggerimenti.

I maintainer dell'archivio mantengono traccia delle sezioni e delle priorità canoniche per i pacchetti presenti nel file override. Se c'è una disparità tra il file override e campi del pacchetto come indicato in debian/control, allora si riceverà una email che sottolinerà la divergenza nel momento in cui il pacchetto viene installato nell'archivio. È possibile correggere il filedebian/control per il successivo caricamento, oppure si potrebbe desiderare di fare un cambiamento nel file di override.

Per modificare la sezione attuale nella quale il pacchetto è stato inserito, è necessario prima assicurarsi che il debian/control nel pacchetto sia preciso. Successivamente, si crei un bug su ftp.debian.org chiedendo che la sezione o la priorità per il pacchetto siano modificati dalla vecchia sezione o priorità a quella nuova. Si utilizzi un Subject del tipo override: Package1: sezione/priorità, [...], PACKAGEX: sezione/priorità, e includere la motivazione per la modifica nel corpo della segnalazione del bug.

Per ulteriori informazioni sugli file di override, si consulti dpkg-scanpackages 1 e https://www.debian.org/Bugs/Developer#maintincorrect.

Si noti che il campo Section descrive sia la sezione che la sottosezione, che sono descritti nella Sezioni. Se la sezione è la principale, dovrebbe essere omessa. L'elenco delle sottosezioni ammissibili può essere trovato in https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections.

5.8. Gestione dei bug

Ogni sviluppatore deve essere capace di lavorare con il Debian bug tracking system. Questo implica la conoscenza di come creare propriamente le segnalazioni di bug (si consulti Segnalare i bug), di come modificarli e riordinarli, e di come processarli e chiuderli.

Le caratteristiche del sistema di tracciamento dei bug sono descritte nella documentazione BTS per gli sviluppatori. Questo include la chiusura bug, l'invio di messaggi di riepilogo, l'assegnazione dei livelli di gravità e tag, il marcare i bug come inoltrati, e altre questioni.

Operazioni quali la riassegnazione di bug ad altri pacchetti, fondendo le segnalazioni di bug separate sullo stesso problema, o la riapertura di bug quando sono chiusi prematuramente, vengono gestite utilizzando il cosiddetto server di controllo di posta elettronica. Tutti i comandi disponibili su questo server sono descritti nella documentazione del server di controllo BTS.

5.8.1. Monitoraggio dei bug

Se si vuole essere un buon maintainer, si dovrebbe verificare periodicamente il Debian bug tracking system (BTS) per i propri pacchetti. Il BTS contiene tutti i bug aperti per i propri pacchetti. È possibile controllarli sfogliando questa pagina: http://bugs.debian.org/yourlogin@debian.org.

I maintainer interagiscono con le BTS attraverso indirizzi di posta elettronica a bugs.debian.org. La documentazione sui comandi disponibili può essere trovata su https://www.debian.org/Bugs/, oppure, se è stato installato il pacchetto doc-debian, è possibile guardare i file locali /usr/share/doc/debian/bug-*.

Alcuni trovano utile avere rapporti periodici sul bug aperti. È possibile aggiungere un processo di cron come segue, se si vuole ottenere una email settimanale che illustra tutti i bug aperti per i propri pacchetti:

# ask for weekly reports of bugs in my packages
0 17 * * fri   echo "index maint address" | mail request@bugs.debian.org

Sostituite address con il proprio indirizzo ufficiale di maintainer Debian.

5.8.2. Rispondere ai bug

When responding to bugs, make sure that any discussion you have about bugs is sent to the original submitter of the bug, the bug itself and (if you are not the maintainer of the package) the maintainer. Sending an email to 123@bugs.debian.org will send the mail to the maintainer of the package and record your email with the bug log. If you don't remember the submitter email address, you can use 123-submitter@bugs.debian.org to also contact the submitter of the bug. The latter address also records the email with the bug log, so if you are the maintainer of the package in question, it is enough to send the reply to 123-submitter@bugs.debian.org. Otherwise you should include 123@bugs.debian.org so that you also reach the package maintainer.

Se si ottiene un bug che cita FTBFS, questo significa non si riesce a compilare dai sorgenti. Gli autori dei port utilizzano spesso questo acronimo.

Una volta che si è affrontata una segnalazione di bug (e.g. correggendolo), lo si contrassegni come done (lo si chiuda) con l'invio di un messaggio di spiegazione a 123-done@bugs.debian.org. Se si sta correggendo un bug modificando e caricando il pacchetto, è possibile automatizzare la chiusura del bug come descritto in Quando i bug vengono chiusi da nuovi upload.

Mai si dovrebbe chiudere un bug tramite il comando del bug server close inviato a control@bugs.debian.org. Se lo fate, il mittente originale non riceverà alcuna informazione sul perché il bug è stato chiuso.

5.8.3. Pulizia dei bug

Come maintainer del pacchetto, spesso si trovano bug in altri pacchetti o si hanno bug segnalati sui propri pacchetti ma che in realtà sono bug di altri pacchetti. Le caratteristiche del sistema di tracciamento dei bug sono descritte nella documentazione BTS per gli sviluppatori Debian. Operazioni come la riassegnazione, l'unione e segnalazioni di bug, l'etichettatura sono descritte nella BTS control server documentation. Questa sezione contiene alcune linee guida per la gestione dei propri bug, sulla base dell'esperienza collettiva degli sviluppatori Debian.

Segnalare bug per problemi che si trovano in altri pacchetti è uno dei doveri civici di maintainer, si consulti Segnalare i bug per i dettagli. Tuttavia, la gestione dei bug nei propri pacchetti è ancora più importante.

Ecco un elenco di passaggi che si possono seguire per gestire una segnalazione di errore:

1. Decidere se la segnalazione corrisponde ad un vero e proprio bug o meno. A volte gli utenti invocano un programma nel modo sbagliato perché non hanno letto la documentazione. Se la diagnosi è questa, basta chiudere il bug con informazioni sufficienti per consentire agli utenti di correggere il loro problema (dare indicazioni sulla buona documentazione e così via). Se la stessa segnalazione viene presentata più e più volte ci si potrebbe chiedere se la documentazione sia sufficiente o se il programma non rilevi il suo cattivo uso al fine di fornire un messaggio di errore. Questo è un problema che può aver bisogno di essere risolto con l'autore originale.

   If the bug submitter disagrees with your decision to close the bug, they may reopen it until you find an agreement on how to handle it. If you don't find any, you may want to tag the bug wontfix to let people know that the bug exists but that it won't be corrected. Please make sure that the bug submitter understands the reasons for your decision by adding an explanation to the message that adds the wontfix tag.

   If this situation is unacceptable, you (or the submitter) may want to require a decision of the technical committee by filing a new bug against the tech-ctte pseudo-package with a summary of the situation. Before doing so, please read the recommended procedure.

2. Se il bug è reale ma è causato da un altro pacchetto, basta riassegnare il bug al pacchetto giusto. Se non si sa a quale pacchetto dovrebbe essere riassegnato, si dovrebbe chiedere aiuto su Canali IRC o su debian-devel@lists.debian.org. Informare il maintainer del pacchetto al quale si riassegna il bug, per esempio mettendo in Cc: al messaggio che fa la riassegnazione a packagename@packages.debian.org e spiegando le proprie motivazioni nel corpo della email. Si noti che una semplice riassegnazione non è inviata ai maintainer del pacchetto al quale viene riassegnato, quindi non avranno modo di saperlo fino a quando consulteranno la panoramica dei bug per i loro pacchetti.

   Se il bug interessa il funzionamento del proprio pacchetto, si consideri di clonare il bug e di riassegnarlo al pacchetto che realmente provoca il comportamento. In caso contrario, il bug non verrà mostrato nella lista dei bug del proprio pacchetto, inducendo gli utenti a segnalare lo stesso problema più e più volte. Si dovrebbe bloccare «il proprio» bug con il bug riassegnato, clonato per documentare la relazione.

3. A volte è necessario anche per regolare la gravità del bug in modo che corrisponda alla propria definizione di gravità. Questo perché le persone tendono a gonfiare la gravità dei bug per assicurarsi che i loro bug siano risolti rapidamente. Alcuni bug possono anche essere lasciati con gravità wishlist quando il cambiamento richiesto è solo estetico.

4. Se il bug è reale, ma lo stesso problema è già stato segnalato da qualcun altro, allora le due segnalazioni di bug rilevanti dovrebbero essere fuse in una sola utilizzando il comando merge del BTS. In questo modo, quando il bug viene corretto, tutti i mittenti ne saranno informati. (Si noti, tuttavia, che i messaggi di posta elettronica inviati al mittente di un solo bug non saranno automaticamente inviati al mittente dell'altra segnalazione.) Per maggiori dettagli sui tecnicismi del comando merge e simili, il comando unmerge, si consulti la documentazione del server di controllo BTS.

5. Il mittente del bug potrebbe aver dimenticato di fornire alcune informazioni, nel qual caso si deve chiedergli le informazioni necessarie. A tal proposito è possibile marcare il bug con il tag moreinfo. Inoltre se non è possibile riprodurre il bug, lo si etichetta come unreproducible. Chiunque può riprodurre il bug è allora invitato a fornire ulteriori informazioni su come riprodurlo. Dopo pochi mesi, se queste informazioni non sono state inviate da nessuno, il bug può essere chiuso.

6. Se il bug è legato alla pacchettizzazione, basta risolvere il problema. Se non si è in grado di risolverlo da soli, allora si contrassegni il bug come help. Si può anche chiedere aiuto su debian-devel@lists.debian.org o debian-qa@lists.debian.org. Se è un problema che riguarda il software originale, è necessario inoltrarlo all'autore originale. L'inoltro di un bug non è sufficiente, è necessario controllare ad ogni rilascio se il bug è stato risolto o meno. Se lo è, basta chiuderlo, altrimenti si deve ricordarlo all'autore. Se si hanno le competenze necessarie si può preparare una patch che corregge il bug e inviarla all'autore allo stesso tempo. Assicurarsi di inviare la patch al BTS e di contrassegnare il bug come patch.

7. Se è stato sistemato un errore nella copia locale, o se una correzione è stata committata nel repository VCS, è possibile identificare il bug come pending, per far sapere che il bug è stato corretto e che sarà chiuso con il prossimo caricamento (si aggiunga closes: nel changelog). Questo è particolarmente utile se si è in diversi sviluppatori che lavorano sullo stesso pacchetto.

8. Once a corrected package is available in the archive, the bug should be closed indicating the version in which it was fixed. This can be done automatically; read Quando i bug vengono chiusi da nuovi upload.

5.8.4. Quando i bug vengono chiusi da nuovi upload

Cosi come bug e problemi sono corretti nei propri pacchetti, è responsabilità del maintainer del pacchetto chiudere questi bug. Tuttavia, non è necessario chiudere un bug fino a quando il pacchetto che corregge il bug è stato accettato nell'archivio Debian. Pertanto, una volta che si ottiene la notifica che il proprio pacchetto aggiornato è stato installato nell'archivio, si può e si deve chiudere il bug nel BTS. Inoltre, il bug dovrebbe essere chiuso con la versione corretta.

Tuttavia, è possibile evitare di dover chiudere manualmente i bug dopo il caricamento - basta elencare i bug corretti nel proprio file debian/changelog, seguendo una certa sintassi, e il software di manutenzione chiuderà il bug. Per esempio:

acme-cannon (3.1415) unstable; urgency=low

  * Frobbed with options (closes: Bug#98339)
  * Added safety to prevent operator dismemberment, closes: bug#98765,
    bug#98713, #98714.
  * Added man page. Closes: #98725.

Tecnicamente parlando, la seguente espressione regolare Perl descrive come i changelog che chiudono dei bug sono identificati:

/closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/ig

We prefer the closes: #XXX syntax, as it is the most concise entry and the easiest to integrate with the text of the changelog. Unless specified differently by the -v-switch to dpkg-buildpackage, only the bugs closed in the most recent changelog entry are closed (basically, exactly the bugs mentioned in the changelog-part in the .changes file are closed).

Storicamente, i caricamenti individuati come Caricamenti dei Non-Maintainer (NMU) sono stati contrassegnati come fixed invece di essere chiusi, ma questa pratica è stata cessata con l'avvento del versionamento. Lo stesso vale per il tag fixed-in-experimental.

If you happen to mistype a bug number or forget a bug in the changelog entries, don't hesitate to undo any damage the error caused. To reopen wrongly closed bugs, send a reopen XXX command to the bug tracking system's control address, control@bugs.debian.org. To close any remaining bugs that were fixed by your upload, email the .changes file to XXX-done@bugs.debian.org, where XXX is the bug number, and put Version: YYY and an empty line as the first two lines of the body of the email, where YYY is the first version where the bug has been fixed.

Tenete a mente che non è obbligatorio chiudere i bug utilizzando il changelog come descritto sopra. Se si vuole semplicemente chiudere bug che non hanno nulla a che vedere con un caricamento che si è fatto, lo si faccia inviando tramite email una spiegazione a XXX-done@bugs.debian.org. Non chiudete bug nella voce del changelog di una versione se le modifiche in quella versione del pacchetto non hanno alcuna attinenza con il bug.

Per informazioni generali su come scrivere i propri contenuti di changelog, si consulti Buone pratiche per il debian/changelog.

5.8.5. Gestione di bug relativi alla sicurezza

A causa della loro natura sensibile, i bug relativi alla sicurezza devono essere maneggiati con cura. Esiste Debian Security Team per coordinare questa attività, tenendo traccia dei problemi di sicurezza in sospeso, aiutando i maintainer con problemi di sicurezza o sistemandoli loro stessi, inviando avvisi di sicurezza, e mantenendo security.debian.org.

Quando si viene a conoscenza di un bug relativo alla sicurezza in un pacchetto Debian, anche se non si è il maintainer, si raccolga informazioni pertinenti in merito al problema, e si contatti immediatamente il team di sicurezza, preferibilmente presentando il ticket nella propria Request Tracker. Si consulti http://wiki.debian.org/rt.debian.org#Security_Team. In alternativa si può mandare una email team@security.debian.org. NON FARE L'UPLOAD di pacchetti per stable senza contattare il team. Le informazioni utili comprendono, per esempio:

• Se il bug è già di dominio pubblico.

• Quali versioni del pacchetto sono note per essere interessate dal bug. Si controlli ogni versione che è presente in un rilascio supportato di Debian, così come testing e unstable.

• La natura della correzione, se qualcuna è disponibile (patch sono particolarmente utili)

• Any fixed packages that you have prepared yourself (send the resulting debdiff or alternatively only the .diff.gz and .dsc files and read Preparazione di pacchetti per indirizzare i problemi di sicurezza first)

• Qualsiasi tipo di assistenza si è in grado di fornire per aiutare con i test (exploit, test di regressione, etc.)

• Tutte le informazioni necessarie per la consulenza (si consulti Avvisi di sicurezza)

Come maintainer del pacchetto, si ha la responsabilità di mantenerlo, anche nella versione stabile. Si è nella posizione migliore per valutare le patch e testare i pacchetti aggiornati, quindi consultare le sezioni di seguito su come preparare i pacchetti per il Security Team.

5.8.5.1. Debian Security Tracker

Il team di sicurezza mantiene una banca dati centrale, il Debian Security Tracker. Questa contiene tutte le informazioni pubbliche che sono note sui problemi di sicurezza: quali pacchetti e versioni sono interessate o corrette, e quindi se stable, testing e/o unstable sono vulnerabili. Informazioni che sono ancora confidenziali non vengono aggiunte al tracker.

È possibile cercare per un problema specifico, ma anche sul nome del pacchetto. Cercare il proprio pacchetto per vedere quali problemi sono ancora aperti. Se è possibile, fornire ulteriori informazioni su questi problemi, o di aiutare ad indirizzarli nel proprio pacchetto. Le istruzioni si trovano sulle pagine web del tracker.

5.8.5.2. Riservatezza

A differenza di molte altre attività all'interno di Debian, le informazioni su problemi di sicurezza devono talvolta essere mantenute private per un certo tempo. Questo consente ai distributori di software di coordinare la loro divulgazione al fine di ridurre al minimo l'esposizione dei loro utenti. Se questo è il caso dipende dalla natura del problema e dalla correzione corrispondente, e se è già di dominio pubblico.

Ci sono diversi modi con cui gli sviluppatori possono venire a conoscenza di problemi di sicurezza:

• è stato notato su un forum pubblico (mailing list, sito web, etc.)

• qualcuno deposita una segnalazione di bug

• qualcuno li informa via email privata

Nei primi due casi, l'informazione è pubblica ed è importante avere una correzione il più presto possibile. Nell'ultimo caso, tuttavia, potrebbe non essere una informazione pubblica. In questo caso ci sono alcune possibili opzioni per affrontare il problema:

• Se l'esposizione di sicurezza è minore, talvolta non è necessario mantenere il problema un segreto e una correzione devrebbe essere fatta e rilasciata.

• Se il problema è grave, è preferibile condividere le informazioni con altri fornitori e coordinare un rilascio. Il team di sicurezza si mantiene in contatto con le varie organizzazioni e gli individui e può prendersi cura di questo.

In tutti i casi, se la persona che segnala il problema chiede di non divulgarlo, tali richieste devono essere onorate, con l'ovvia eccezione di informare il team di sicurezza in modo che una soluzione possa essere prodotta per un rilascio stabile di Debian. Quando si inviano informazioni riservate al team di sicurezza, ci si assicuri di indicare questo fatto.

Si tenga presente che se è necessaria la segretezza non si può caricare una correzione in unstable (o in qualsiasi altro luogo, come un repository pubblico VCS). Non è sufficiente offuscare i dettagli della modifica, dato che il codice stesso è pubblico, e può (e sarà) esaminato dal pubblico in generale.

Ci sono due motivi per il rilascio di informazioni anche se è richiesto il segreto: il problema è conosciuto da un po', o il problema o l'exploit è diventato pubblico.

Il team di sicurezza ha un PGP-key per abilitare la comunicazione crittografata su questioni delicate. Si consulti la Security Team FAQ per i dettagli.

5.8.5.3. Avvisi di sicurezza

Gli avvisi di sicurezza vengono rilasciati solo per la corrente, rilasciata distribuzione stabile, e non per testing o unstable. Quando viene rilasciata, gli avvisi vengono inviati alla mailing list debian-security-announce@lists.debian.org e pubblicate sulla pagina web di sicurezza. Gli avvisi di sicurezza sono scritti e pubblicati dal team di sicurezza. Ma di certo non ci restano male se un maintainer è in grado di fornirgli alcune delle informazioni, o scrivere una parte del testo. Le informazioni che devono essere presenti in un avviso comprendono:

• Una descrizione del problema e il suo campo di applicazione, tra cui:

  • Il tipo di problema (l'escalation dei privilegi, denial of service, etc.)

  • Quali privilegi possono essere acquisiti, e da chi (se alcuni)

  • Come può essere sfruttata

  • Se è sfruttabile da remoto o in locale

  • Come è stato risolto il problema

  Queste informazioni consentono agli utenti di valutare la minaccia per i loro sistemi.

• Numeri di versione dei pacchetti coinvolti

• Numeri di versione dei pacchetti corretti

• Informazioni su dove ottenere i pacchetti aggiornati (di solito dall'archivio di sicurezza di Debian)

• I riferimenti agli avvisi originali, identificatori CVE, e ogni altra informazione utile nel documentare la vulnerabilità

5.8.5.4. Preparazione di pacchetti per indirizzare i problemi di sicurezza

Un modo con cui si può aiutare il team di sicurezza nei suoi compiti è quello di fornirgli pacchetti corretti adatti per un avviso di sicurezza per il rilascio stabile di Debian.

When an update is made to the stable release, care must be taken to avoid changing system behavior or introducing new bugs. In order to do this, make as few changes as possible to fix the bug. Users and administrators rely on the exact behavior of a release once it is made, so any change that is made might break someone's system. This is especially true of libraries: make sure you never change the API (Application Program Interface) or ABI (Application Binary Interface), no matter how small the change.

Ciò significa che il passaggio a una nuova versione originale non è una buona soluzione. Invece, le rilevanti modifiche devono essere adattate alla versione presente nella attuale rilascio stabile di Debian. In generale, i maintainer originali sono disposti ad aiutare se necessario. In caso contrario, il team di sicurezza di Debian può essere in grado di aiutare.

In alcuni casi, non è possibile adattare una correzione di sicurezza, per esempio quando grandi quantità di codice sorgente dovrebbero essere modificate o riscritte. Se questo accade, può essere necessario passare ad una nuova versione. Tuttavia, questo è fatto solo in situazioni estreme, e ci si deve sempre coordinare che con il team della sicurezza.

A questo si collega un'altra importante linea guida: verificare sempre le modifiche. Se si dispone di un exploit, provare e vedere se davvero ha avuto successo sul pacchetto senza patch e fallisce sul pacchetto corretto. Provare altre, anche normali azioni, dato che a volte una correzione di sicurezza può rompere in modi sottili caratteristiche apparentemente non correlate.

NON includere eventuali modifiche nel proprio pacchetto che non sono direttamente collegate alla correzione della vulnerabilità. Queste avranno bisogno solo di essere annullate, e questo richiede tempo. Se ci sono altri bug nel pacchetto che si desidera correggere, si faccia un caricamento su proposed-updates nel solito modo, dopo che l'avviso di sicurezza viene pubblicato. Il meccanismo di aggiornamento della sicurezza non è un mezzo per introdurre modifiche al pacchetto che altrimenti verrebbero respinte per il rilascio stabile, quindi per favore non si tenti di farlo.

Si verifichino e testino le modifiche per quanto possibile. Si controllino ripetutamente le differenze rispetto alla versione precedente (interdiff dal pacchetto patchutils e debdiff da devscripts sono strumenti utili per questo, si consulti debdiff).

Assicurarsi di verificare i seguenti elementi:

• Individuare la giusta distribuzione nel proprio debian/changelog. Per stable questa è stable-security e per testing questa è testing-security, e per la precedente versione stable, questa è oldstable-security. Non si punti a distribution-proposed-updates o stable!

• Si creino voci descrittive e significative nel changelog. Altri faranno affidamento su di loro per determinare se un particolare bug è stato risolto. Si aggiungano istruzioni closes: per eventuali bug di Debian pubblicati. Sempre includete un riferimento esterno, preferibilmente un identificatore CVE, in modo che ci possa essere un riferimento incrociato. Tuttavia, se un identificatore CVE non è ancora stato assegnato, non attenderlo ma continuare il processo. L'identificatore può essere referenziato più tardi.

• Assicurarsi che il version number sia corretto. Esso deve essere maggiore del pacchetto corrente, ma minore delle versioni del pacchetto in distribuzioni successive. In caso di dubbio, provare con dpkg - compare-versions. Fare attenzione a non riutilizzare un numero di versione che è già stato utilizzato per un caricamento precedente, o uno che è in conflitto con un binNMU. La convenzione è quella di aggiungere +codename 1, ad esempio, 1:2.4.3-4+lenny1, ovviamente aumentando di 1 ad ogni aggiornamento successivo.

• A meno che il sorgente originale sia stato prima caricato su security.debian.org (grazie ad un aggiornamento di sicurezza precedente), costruite il file da caricare con tutto il codice originale (dpkg-buildpackage -sa). Se vi è stato un precedente caricamento su security.debian.org con la stessa versione dell'originale, si può caricare senza sorgenti originali (dpkg-buildpackage -sd).

• Assicurarsi di utilizzare esattamente lo stesso``*.orig.tar.{gz,bz2,xz}`` come usato nell'archivio normale, altrimenti non è possibile spostare la correzione di sicurezza negli archivi principali dopo.

• Si compili il pacchetto su un sistema pulito, che ha installati solo i pacchetti della distribuzione per la quale si sta costruendo. Se non si dispone di un tale sistema, è possibile utilizzare una macchina di debian.org (si consulti Le macchine Debian) oppure si configuri un chroot (si consulti pbuilder e debootstrap).

5.8.5.5. Caricamento del pacchetto corretto

Do NOT upload a package to the security upload queue (on *.security.upload.debian.org) without prior authorization from the security team. If the package does not exactly meet the team's requirements, it will cause many problems and delays in dealing with the unwanted upload.

NON caricare la correzione su proposed-updates, senza coordinarsi con il team di sicurezza. I pacchetti da security.debian.org saranno copiati nella cartella proposed-updates automaticamente. Se un pacchetto con lo stesso numero di versione o uno più alto è già installato nell'archivio, l'aggiornamento per la sicurezza sarà rifiutato dal sistema di archiviazione. In questo modo, la distribuzione stabile non avrà un aggiornamento di sicurezza per questo pacchetto.

Once you have created and tested the new package and it has been approved by the security team, it needs to be uploaded so that it can be installed in the archives. For security uploads, the place to upload to is ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue/.

Una volta che un caricamento nella coda di sicurezza è stato accettato, il pacchetto viene automaticamente compilato per tutte le architetture e conservato per la verifica da parte del team di sicurezza.

Uploads that are waiting for acceptance or verification are only accessible by the security team. This is necessary since there might be fixes for security problems that cannot be disclosed yet.

Se un membro del team di sicurezza accetta un pacchetto, verrà installato su security.debian.org, così come proposto per la corretta distribution-proposed-updates in ftp-master.debian.org.

5.9. Lo spostamento, la rimozione, la ridenominazione, l'adozione, e rendere orfani i pacchetti

Alcune operazioni di manipolazione di archivi non sono automatizzate nel processo di caricamento di Debian. Queste procedure devono essere seguite manualmente dai maintainer. Questo capitolo fornisce le linee guida su cosa fare in questi casi.

5.9.1. Spostare i pacchetti

A volte un pacchetto cambierà la sua sezione. Per esempio, un pacchetto dalla sezione non-free potrebbe essere GPLizzato in una versione successiva, nel qual caso il pacchetto dovrebbe essere spostato in «main» o «contrib». [1]

Se è necessario modificare la sezione per uno dei propri pacchetti, si modifichino le informazioni di controllo del pacchetto per far posizionare il pacchetto nella sezione desiderata, e caricare nuovamente il pacchetto (si consulti il Debian Policy Manual per i dettagli). È necessario assicurarsi di includere il .orig.tar.{gz,bz2,xz} nel proprio caricamento (anche se non si sta caricando una nuova versione), oppure non comparirà nella nuova sezione insieme al resto del pacchetto. Se la nuova sezione è valida, verrà spostata automaticamente. Se non lo è, allora si contatti gli ftpmasters per capire cosa è successo.

Se, d'altra parte, è necessario modificare la subsection di uno dei pacchetti (per esempio, «devel», «admin»), la procedura è leggermente diversa. Correggete la subsection come si trova nel file di controllo del pacchetto, e caricatelo nuovamente. Inoltre, è necessario per avere il file di override aggiornato, come descritto in Specificare la sezione del pacchetto, sottosezione e la priorità.

5.9.2. Rimozione dei pacchetti

If for some reason you want to completely remove a package (say, if it is an old compatibility library which is no longer required), you need to file a bug against ftp.debian.org asking that the package be removed; as with all bugs, this bug should normally have normal severity. The bug title should be in the form RM: package [architecture list] -- reason, where package is the package to be removed and reason is a short summary of the reason for the removal request. [architecture list] is optional and only needed if the removal request only applies to some architectures, not all. Note that the reportbug will create a title conforming to these rules when you use it to report a bug against the ftp.debian.org pseudo-package.

If you want to remove a package you maintain, you should note this in the bug title by prepending ROM (Request Of Maintainer). There are several other standard acronyms used in the reasoning for a package removal; see https://ftp-master.debian.org/removals.html for a complete list. That page also provides a convenient overview of pending removal requests.

Note that removals can only be done for the unstable, experimental and stable distributions. Packages are not removed from testing directly. Rather, they will be removed automatically after the package has been removed from unstable and no package in testing depends on it. (Removals from testing are possible though by filing a removal bug report against the release.debian.org pseudo-package. See Rimozioni da testing.)

C'è una sola eccezione quando una richiesta di rimozione esplicita non è necessaria: se un pacchetto (sorgente o binario) non è più compilato dal sorgente, verrà rimosso in modo semiautomatico. Per un pacchetto binario, questo significa che se non vi è più alcun pacchetto sorgente che produce questo pacchetto binario; se il pacchetto binario non è più prodotto per alcune architetture, una richiesta di rimozione è ancora necessaria. Per un pacchetto sorgente, questo significa che tutti i pacchetti binari che a lui si riferiscono devono riferirsi ad un altro pacchetto sorgente.

Nella vostra richiesta di rimozione, è necessario dettagliare le ragioni che giustificano la richiesta. Questo per evitare rimozioni indesiderate e per tenere traccia del perché un pacchetto è stato rimosso. Ad esempio, è possibile specificare il nome del pacchetto che sostituisce quello che deve essere rimosso.

Di solito si chiede solo per la rimozione di un pacchetto che si sta mentenendo. Se si desidera rimuovere un altro pacchetto, è necessario ottenere l'approvazione del suo maintainer. Se il pacchetto resta orfano e quindi non ha un maintainer, si deve prima discutere la richiesta di rimozione su debian-qa@lists.debian.org. Se c'è un consenso sul fatto che il pacchetto debba essere rimosso, è necessario riassegnare e rinominare la segnalazione del bug O: presentato sul pacchetto wnpp invece di presentare un nuovo bug come richiesta di rimozione.

Further information relating to these and other package removal related topics may be found at https://wiki.debian.org/ftpmaster_Removalsand https://qa.debian.org/howto-remove.html.

If in doubt concerning whether a package is disposable, email debian-devel@lists.debian.org asking for opinions. Also of interest is the apt-cache program from the apt package. When invoked as apt-cache showpkg package, the program will show details for package, including reverse depends. Other useful programs include apt-cache rdepends, apt-rdepends, build-rdeps (in the devscripts package) and grep-dctrl. Removal of orphaned packages is discussed on debian-qa@lists.debian.org.

Una volta che il pacchetto è stato rimosso, i bug del pacchetto devono essere gestiti. Essi dovrebbero essere riassegnati ad un altro pacchetto nel caso in cui il codice vero e proprio si sia evoluto in un altro pacchetto (ad esempio libfoo12 è stato rimosso perché libfoo13 lo sostituisce) o chiuso, se il software semplicemente non fa più parte di Debian. Quando si chiude il bug, per evitare di segnare i bug corretti in versioni di pacchetti di rilasci precedenti di Debian, dovrebbero essere contrassegnati come corretti nella versione <most-recent-version-ever-in-Debian>+rm.

5.9.2.1. Rimozione di pacchetti da Incoming

In the past, it was possible to remove packages from incoming. However, with the introduction of the new incoming system, this is no longer possible. [4] Instead, you have to upload a new revision of your package with a higher version than the package you want to replace. Both versions will be installed in the archive but only the higher version will actually be available in unstable since the previous version will immediately be replaced by the higher. However, if you do proper testing of your packages, the need to replace a package should not occur too often anyway.

5.9.3. La sostituzione o la ridenominazione dei pacchetti

Quando i maintainer originali a causa di uno dei propri pacchetti hanno scelto di rinominare il loro software (o si è commesso un errore nel nominare il proprio pacchetto), si dovrebbe seguire un processo in due fasi per rinominarlo. Nella prima fase, modificare il file debian/control affinché rifletta il nuovo nome e per sostituire, prevedete e risolvete eventuali conflitti con il nome del pacchetto obsoleto (si consulti Debian Policy Manual per i dettagli). Si tenga presente che si deve solo aggiungere una relazione Provides se tutti i pacchetti dipendenti dall'obsoleto nome del pacchetto continuano a funzionare dopo la ridenominazione. Una volta caricato il pacchetto e il pacchetto è spostato nell'archivio, si apra un bug nei confronti di ftp.debian.org chiedendo di rimuovere il pacchetto con il nome obsoleto (si veda Rimozione dei pacchetti). Non si dimentichi allo stesso tempo di riassegnare correttamente i bug del pacchetto.

Altre volte, si può fare un errore nella compilazione del proprio pacchetto e si vuole sostituirlo. L'unico modo per farlo è aumentare il numero di versione e caricarlo. La vecchia versione scadrà nel modo consueto. Si noti che questo vale per ogni parte del proprio pacchetto, compresi i sorgenti: se si desidera sostituire l'archivio dei sorgenti originali del proprio pacchetto, è necessario caricarlo con una versione diversa. Un modo semplice è quello di sostituire foo_1.00.orig.tar.gz con foo_1.00+0.orig.tar.gz o foo_1.00.orig.tar.bz2. Questa restrizione dà ad ogni file sul sito FTP un nome unico, che contribuisce a garantire la coerenza tra i mirror.

5.9.4. Pacchetto orfano

If you can no longer maintain a package, you need to inform others, and see that the package is marked as orphaned. You should set the package maintainer to Debian QA Group <packages@qa.debian.org> and submit a bug report against the pseudo package wnpp. The bug report should be titled O: package -- short description indicating that the package is now orphaned. The severity of the bug should be set to normal; if the package has a priority of standard or higher, it should be set to important. If you feel it's necessary, send a copy to debian-devel@lists.debian.org by putting the address in the X-Debbugs-CC: header of the message (no, don't use CC:, because that way the message's subject won't indicate the bug number).

If you just intend to give the package away, but you can keep maintainership for the moment, then you should instead submit a bug against wnpp and title it RFA: package -- short description. RFA stands for Request For Adoption.

Maggiori informazioni si possono trovare nelle pagine web di WNPP.

5.9.5. L'adozione di un pacchetto

Un elenco di pacchetti che necessitano di un nuovo maintainer è disponibile nella Work-Needing and Prospective Packages list(WNPP). Se si desidera prendere in consegna la manutenzione di uno qualsiasi dei pacchetti elencati nella WNPP, si prega di dare un'occhiata alla pagina di cui sopra per informazioni e procedure.

It is not OK to simply take over a package without assent of the current maintainer — that would be package hijacking. You can, of course, contact the current maintainer and ask them for permission to take over the package.

However, when a package has been neglected by the maintainer, you might be able to take over package maintainership by following the package salvaging process as described in Package Salvaging. If you have reason to believe a maintainer is no longer active at all, see Rapportarsi con maintainer non attivi e/o non raggiungibili.

Complaints about maintainers should be brought up on the developers' mailing list. If the discussion doesn't end with a positive conclusion, and the issue is of a technical nature, consider bringing it to the attention of the technical committee (see the technical committee web page for more information).

Se si rileva un vecchio pacchetto, probabilmente si vuole essere elencati come maintainer ufficiale del pacchetto nel sistema di tracciamento dei bug. Questo avverrà automaticamente una volta che si carica una nuova versione con un campo Maintainer aggiornato, anche se può richiedere alcune ore dopo che il caricamento sia stato fatto. Se non si prevede di caricare una nuova versione per un po', è possibile utilizzare The Debian Package Tracker per ottenere le segnalazioni di bug. Tuttavia, ci si assicuri che il vecchio maintainer non abbia alcun problema con il fatto che in quel periodo continuerà a ricevere le segnalazioni dei bug.

5.9.6. Reintrodurre pacchetti

I pacchetti sono spesso rimossi a causa di bug critici, manutentori assenti, troppo pochi utenti o di scarsa qualità in generale. Mentre il processo di reintroduzione è simile al processo di pacchettizzazione iniziale, è possibile evitare alcune insidie facendo prima qualche ricerca storica.

Si dovrebbe verificare il motivo per cui il pacchetto è stato rimosso, in primo luogo. Queste informazioni si possono trovare nella voce rimozione nella sezione news della pagina PTS per il pacchetto o sfogliando il registro dirimossi. Il bug rimozione vi dirà il motivo per cui il pacchetto è stato rimosso e darà qualche indicazione di ciò che è necessario correggere al fine di reintrodurre il pacchetto. Può indicare che il modo migliore di procedere è quello di passare a qualche altro pezzo di software, invece di reintrodurre il pacchetto.

Può essere opportuno contattare gli ex manutentori per scoprire se si sta lavorando per reintrodurre il pacchetto, interessati a co-mantenimento del pacchetto o interessati a sponsorizzare il pacchetto, se necessario.

Si dovrebbe fare tutto ciò di necessario prima di introdurre nuovi pacchetti (Nuovi pacchetti).

You should base your work on the latest packaging available that is suitable. That might be the latest version from unstable, which will still be present in the snapshot archive.

Il sistema di controllo della versione utilizzata dal manutentore precedente potrebbe modifiche utili, quindi potrebbe essere una buona idea dare un'occhiata lì. Controllare se il file controllo del pacchetto precedente conteneva intestazioni di collegamento al sistema di controllo della versione per il pacchetto e se esiste ancora.

La rimozione di pacchetti da unstable (not testing, stable or oldstable) fa scattare la chiusura di tutti i bug relativi al pacchetto . Si dovrebbe guardare attraverso tutti i bug chiusi (compresi bug archiviati) ed estrarre e riaprire qualunque sia stato chiuso in una versione che termina in +rm e applicare nuovamente. Qualunque che non si applichi deve essere contrassegnato come risolto nella versione corretta se si è a conoscenza.

Package removals from unstable also trigger marking the package as removed in the Debian Security Tracker. Debian members should mark removed issues as unfixed in the security tracker repository and all others should contact the security team to report reintroduced packages.

5.10. Fare port e port del proprio lavoro

Debian supporta un numero sempre crescente di architetture. Anche se non si è un autore di port, e si utilizza una sola architettura, è parte del dovere di un maintainer essere a conoscenza dei problemi di portabilità. Pertanto, anche se non si è un porter, si consiglia di leggere la maggior parte di questo capitolo.

Porting is the act of building Debian packages for architectures that are different from the original architecture of the package maintainer's binary package. It is a unique and essential activity. In fact, porters do most of the actual compiling of Debian packages. For instance, when a maintainer uploads a (portable) source package with binaries for the i386 architecture, it will be built for each of the other architectures, amounting to 10 more builds.

5.10.1. Siate gentili con gli autori di port

Gli autori di port hanno un compito difficile e unico, poiché sono necessari per affrontare una grande mole di pacchetti. Idealmente, ogni pacchetto sorgente dovrebbe potersi compilare così come è. Purtroppo, spesso questo non è vero. Questa sezione contiene un elenco di «cose da tenere d'occhio» spesso committitate dai maintainer Debian: problemi comuni che spesso ostacolano gli autori di port, e rendono il loro lavoro inutilmente difficile.

The first and most important thing is to respond quickly to bugs or issues raised by porters. Please treat porters with courtesy, as if they were in fact co-maintainers of your package (which, in a way, they are). Please be tolerant of succinct or even unclear bug reports; do your best to hunt down whatever the problem is.

Di gran lunga, la maggior parte dei problemi incontrati dagli autori di port sono causati da bug di pacchettizzazione dei pacchetti sorgente. Ecco una lista di cose che dovreste controllare o di cui dovreste essere a conoscenza.

1. Make sure that your Build-Depends and Build-Depends-Indep settings in debian/control are set properly. The best way to validate this is to use the debootstrap package to create an unstable chroot environment (see debootstrap). Within that chrooted environment, install the build-essential package and any package dependencies mentioned in Build-Depends and/or Build-Depends-Indep. Finally, try building your package within that chrooted environment. These steps can be automated by the use of the pbuilder program, which is provided by the package of the same name (see pbuilder).

   Se non è possibile impostare una corretta chroot, dpkg-depcheck può essere di aiuto (si consulti dpkg-depcheck).

   Si consulti il Debian Policy Manual per le istruzioni su come impostare le dipendenze di compilazione.

2. Non si imposti l'architettura a un valore diverso da all o any a meno che non si voglia veramente farlo. In troppi casi, i maintainer non seguono le istruzioni del Debian Policy Manual. Impostare l'architettura ad una sola (come ad esempio i386 o amd64) è di solito non corretto.

3. Make sure your source package is correct. Do dpkg-source -x package.dsc to make sure your source package unpacks properly. Then, in there, try building your package from scratch with dpkg-buildpackage.

4. Assicuratevi di non distribuire il pacchetto sorgente con il debian/files o debian/substvars. Essi devono essere rimossi dal target clean di debian/rules.

5. Make sure you don't rely on locally installed or hacked configurations or programs. For instance, you should never be calling programs in /usr/local/bin or the like. Try not to rely on programs being set up in a special way. Try building your package on another machine, even if it's the same architecture.

6. Non dipendere dal fatto che il pacchetto che si sta compilando sia già installato (un sotto-caso del problema di cui sopra). Ci sono, naturalmente, eccezioni a questa regola, ma si sia consapevoli che qualsiasi caso come questo necessita di bootstrap manuale e dagli strumenti per compilazione automatica dei pacchetti.

7. Non fate affidamento su una particolare versione del compilatore, se possibile. In caso contrario, assicurarsi che le dipendenze di compilazione rispecchino le restrizioni, anche se probabilmente si andrà incontro a guai, poiché diverse architetture a volte si standardizzano su compilatori diversi.

8. Assicurarsi che il proprio debian/rules contenga target separati per binary-arch e binary-indep, come richiede il Debian Policy Manual. Assicurarsi che entrambi i target lavorino indipendentemente, cioè, che sia possibile chiamare il target senza aver prima chiamato l'altro. Per verificarlo, provate ad eseguire dpkg-buildpackage -B.

9. When you can't support your package on a particular architecture, you shouldn't use the Architecture field to reflect that (it's also a pain to maintain correctly). If the package fails to build from source, you can just let it be and interested people can take a look at the build logs. If the package would actually build, the trick is to add a Build-Depends on unsupported-architecture [!the-not-supported-arch]. The buildds will not build the package as the build dependencies are not fullfiled on that arch. To prevent building on 32-bits architectures, the architecture-is-64bit build dependency can be used, as architecture-is-little-endian can be used to prevent building on big endian systems.

5.10.2. Linee guida per i caricamenti degli autori di port

Se il pacchetto si compila senza modifiche per l'architettura per la quale si sta facendo il port, si è fortunati e il proprio compito è semplice. Questa sezione si applica a questo caso, descrive come compilare e caricare il pacchetto binario in modo che sia correttamente installato nell'archivio. Se c'è bisogno di creare una patch per il pacchetto in modo da farlo compilare per le altre architetture, si sta effettivamente facendo un NMU di un sorgente, dunque si consultino le Quando e come fare un NMU.

Per un caricamento effettuato da un autore di port, nessuna modifica deve essere stata fatta al sorgente. Non è necesssario toccare alcun file nel pacchetto sorgente. Questo include debian/changelog.

The way to invoke dpkg-buildpackage is as dpkg-buildpackage -B -m porter-email. Of course, set porter-email to your email address. This will do a binary-only build of only the architecture-dependent portions of the package, using the binary-arch target in debian/rules.

Se si sta lavorando su una macchina Debian per fare il port e si ha bisogno di firmare il proprio caricamento localmente per la sua accettazione nell'archivio, è possibile eseguire debsign sul proprio file .changes per averlo comodamente firmato, oppure si utilizzi la modalità di firma remota dpkg-sig.

5.10.2.1. Ricompilazione o NMU dei soli binari

A volte il primo caricamento di un autore di port è problematico perché l'ambiente in cui il pacchetto è stato compilato non era abbastanza buono (librerie datate o obsolete, un compilatore non buono, etc.). Allora si può solo aver necessità di ricompilarlo in un ambiente aggiornato. Tuttavia, è necessario incrementare il numero della versione, in questo caso, in modo che il vecchio non buono pacchetto possa essere sostituito nell'archivio Debian (dak si rifiuta di installare nuovi pacchetti, se non hanno un numero di versione maggiore di quella attualmente disponibile).

Si deve fare in modo che il proprio NMU di soli binari non renda il pacchetto non installabile. Questo potrebbe accadere quando un pacchetto sorgente genera pacchetti dipendenti e non dall'architettura che possiedono inter-dipendenze generate utilizzando la variabile di sostituzione di dpkg $(Source-Version).

Nonostante la modifica necessaria del changelog, questi sono chiamati NMU di soli binari: non è necessario in questo caso far sì che tutte le altre architetture si considerino non aggiornate o con necessità di ricompilazione.

Tali ricompilazioni richiedono un particolare numero di versione «magico», in modo che gli strumenti di manutenzione dell'archivio riconoscano che, anche se vi è una nuova versione di Debian, non vi è alcun aggiornamento di sorgenti corrispondente. Se si sbaglia, i manutentori dell'archivio respingeranno il proprio caricamento (per mancanza del corrispondente codice sorgente).

Il «magico» per un NMU con sola ricompilazione viene attivato utilizzando un suffisso aggiunto al numero di versione del pacchetto, seguendo la forma bnumero. Per esempio, se l'ultima versione sulla quale si sta ricompilando era la versione 2.9-3, l'NMU solo binario dovrebbe avere la versione 2.9-3+b1. Se l'ultima versione era 3.4+b1 (cioè un pacchetto nativo con un precedente NMU con ricompilazione), il proprio NMU solo binario dovrebbe avere un numero di versione 3.4+b2. [2]

In modo simile ai caricamenti iniziali dell'autore del port, il modo corretto di invocare dpkg-buildpackage è dpkg-buildpackage -B per compilare solo le parti del pacchetto dipendenti dell'architettura.

5.10.2.2. Quando fare un NMU del sorgente se si è un autore di port

Gli autori di port generalmente nel fare un NMU del sorgente seguono le linee guida presenti in Caricamenti dei Non-Maintainer (NMU), proprio come i non-porter. Tuttavia, ci si aspetta che il ciclo di attesa per un NMU del sorgente di un autore di port sia minore di quello per chi non è autore di port, poiché i gli autori di port devono gestire una grande quantità di pacchetti. Di nuovo, la situazione varia a seconda della distribuzione sulla quale si stanno effettuando i caricamenti. Essa varia anche se l'architettura è candidata ad essere inclusa nel prossimo rilascio stabile; i gestori dei rilasci decidono e annunciano quali architetture sono candidate.

Se si è un autore di port che fa un NMU per unstable, le linee guida di cui sopra per la portabilità dovrebbero essere seguite, con due varianti. In primo luogo, il periodo di attesa accettabile, il tempo tra quando il bug è presentato al BTS e quando è considerato valido per fare un NMU, è di sette giorni per gli autori di port che lavorano sulla distribuzione unstable. Questo periodo può essere abbreviato se il problema è critico e crea difficoltà sul lavoro di creazione dei port, a discrezione del gruppo di lavoro sui port. (Ricordate, niente di tutto ciò è Policy, ma solo linee guida stabilite di comune accordo.) Per caricamenti su stable o su testing, coordinarsi prima con l'appropriato team di rilascio.

In secondo luogo, gli autori di port che fanno NMU di sorgenti dovrebbero assicurarsi che il bug presentato al BTS dovrebbe essere di gravità serious o superiore. Questo assicura che un singolo pacchetto sorgente possa essere usato per compilare ogni architettura supportata da Debian al momento del rilascio. È molto importante avere una versione del pacchetto binario e di quello del sorgente per tutte le architetture al fine di conformarsi con molte licenze.

Gli autori dei port dovrebbero cercare di evitare le patch che semplicemente aggirano i bug nella versione attuale dell'ambiente di compilazione, kernel, oppure libc. A volte tali stratagemmi non possono essere evitati. Se è necessario aggirare bug del compilatore e simili, assicurarsi di #ifdef il proprio lavoro correttamente; inoltre, documentare le modifiche fatte per aggirare i bug in modo che la gente sappia di rimuoverli una volta che i problemi esterni siano stati corretti.

Gli autori di port possono anche avere un luogo non ufficiale dove possono mettere i risultati del loro lavoro durante il periodo di attesa. Questo aiuta gli altri che utilizzano il port ad avere il vantaggio del lavoro del suo autore, anche durante il periodo di attesa. Naturalmente, tali luoghi non hanno alcuna benedizione o status ufficiale, quindi stare attenti.

5.10.3. Infrastrutture e automazione per il port

C'è un'infrastruttura e diversi strumenti per aiutare ad automatizzare il port dei pacchetti. Questa sezione contiene una breve panoramica di questi strumenti di automazione e di port; si consulti la documentazione dei pacchetti o i riferimenti per informazioni complete.

5.10.3.1. Mailing list e pagine web

Le pagine Web che contengono lo stato di ogni porto sono disponibili all'indirizzo https://www.debian.org/ports/.

Ogni port di Debian ha una mailing list. L'elenco delle mailing list dedicate ai port può essere trovato su https://lists.debian.org/ports.html. Questi elenchi vengono utilizzati per coordinare gli autori di port, e per collegare gli utenti di un dato port con gli autori.

5.10.3.2. Strumenti per gli autori di port

Le descrizioni di diversi strumenti per il port si possono trovare su Strumenti per i port.

5.10.3.3. wanna-build

The wanna-build system is used as a distributed, client-server build distribution system. It is usually used in conjunction with build daemons running the buildd program. Build daemons are slave hosts, which contact the central wanna-build system to receive a list of packages that need to be built.

wanna-build is not yet available as a package; however, all Debian porting efforts are using it for automated package building. The tool used to do the actual package builds, sbuild, is available as a package; see its description in sbuild. Please note that the packaged version is not the same as the one used on build daemons, but it is close enough to reproduce problems.

Most of the data produced by wanna-build that is generally useful to porters is available on the web at https://buildd.debian.org/. This data includes nightly updated statistics, queueing information and logs for build attempts.

Siamo molto orgogliosi di questo sistema, dal momento che ha tanti usi possibili. Gruppi di sviluppo indipendenti possono utilizzare il sistema per diverse sotto-versioni di Debian, che possono o non possono essere di interesse generale (per esempio, una versione di Debian compilata con il bound-checking di gcc). Essa consentirà inoltre a Debian di ricompilare intere distribuzioni rapidamente.

Il team di wanna-build, responsabile dei buildd, può essere raggiunto all'indirizzo debian-wb-team@lists.debian.org. Per determinare chi contattare (team di wanna-build, team del rilascio) e come (posta, BTS), si faccia riferimento a https://lists.debian.org/debian-project/2009/03/msg00096.html.

Quando si richiedono dei binNMUs o dei give-backs (un nuovo tentativo dopo una compilazione fallita), utilizzare il formato descritto in https://release.debian.org/wanna-build.txt.

5.10.4. Quando il pacchetto non è portabile

Alcuni pacchetti hanno ancora problemi con la compilazione o con il funzionamento su alcune delle architetture supportate da Debian, ed è del tutto impossibile farne il port, o non entro un ragionevole lasso di tempo. Un esempio è un pacchetto che è SVGA-specifico (disponibile solo per i386 e amd64), o che utilizzi altre caratteristiche specifiche dell'hardware non supportate su tutte le architetture.

Al fine di evitare che pacchetti danneggiati vengano caricati nell'archivio, e sprecare tempo dei buildd, è necessario fare un paio di cose:

• In primo luogo, assicurarsi che il pacchetto fallisca la compilazione su architetture che non supporta. Ci sono alcuni modi per raggiungere questo obiettivo. Il modo migliore è quello di avere una piccola suite di test che ne verifichi le funzionalità durante la compilazione, e che fallirà se non funziona. Questa è comunque una buona idea, in modo da evitare (alcuni) caricamenti difettosi in tutte le architetture, e permetterà anche al pacchetto di compilarsi appena la funzionalità richiesta viene resa disponibile.

  Inoltre, se si ritiene che l'elenco delle architetture supportate sia piuttosto costante, si dovrebbe cambiare any in un elenco delle architetture supportate in debian/control. In questo modo, anche la compilazione fallirà, e lo indicherà ad un lettore umano senza che realmente la si tenti.

• Al fine di evitare che gli strumenti di compilazione automatica cerchino dal cercare inutilmente di compilare il pacchetto, deve essere incluso in Packages-arch-specific, un elenco utilizzato dallo script wanna-build. L'attuale versione è disponibile come https://wiki.debian.org/PackagesArchSpecific; consultare la parte iniziale del file per chi contattare per le modifiche.

Please note that it is insufficient to only add your package to Packages-arch-specific without making it fail to build on unsupported architectures: A porter or any other person trying to build your package might accidentally upload it without noticing it doesn't work. If in the past some binary packages were uploaded on unsupported architectures, request their removal by filing a bug against ftp.debian.org.

5.10.5. Marcare i pacchetti non-free come compilabili automaticamente

By default packages from the non-free and non-free-firmware sections are not built by the autobuilder network (mostly because the license of the packages could disapprove). To enable a package to be built, you need to perform the following steps:

1. Si controlli se è legalmente consentito e tecnicamente possibile automatizzare la compilazione del pacchetto;

2. Si aggiunga XS-Autobuild: yes nell'intestazione di debian/control;

3. Send an email to non-free@buildd.debian.org and explain why the package can legitimately and technically be auto-built.

5.11. Caricamenti dei Non-Maintainer (NMU)

Ogni pacchetto ha uno o più maintainer. Normalmente, queste sono le persone che ci lavorano e caricano nuove versioni del pacchetto. In alcune situazioni è utile che anche altri sviluppatori possano caricare una nuova versione, per esempio se vogliono risolvere un bug in un pacchetto che non mantengono, quando il maintainer ha bisogno di aiuto per rispondere alle segnalazioni. Tali aggiornamenti sono chiamati Non-Maintainer Upload (NMU).

5.11.1. Quando e come fare un NMU

Prima di fare un NMU, si considerino le seguenti domande:

• Il proprio NMU davvero corregge i bug? Risolvere problemi superficiali o cambiare lo stile di pacchettizzazione è scoraggiato in una NMU.

• Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g. wishlist bugs for packaging a new upstream version, but care should be taken to minimize the impact to the maintainer.) Fixing cosmetic issues or changing the packaging style in NMUs is discouraged.

• Quanto si è sicuri delle modifiche? Si ricordi il giuramento di Ippocrate: «Prima di tutto, non nuocere.» È meglio lasciare un pacchetto con un bug grave aperto che applicare una patch non funzionante, o una che nasconde il bug invece di risolverlo. Se non si è sicuri al 100% di quello che si è fatto, potrebbe essere una buona idea chiedere il parere di altri. Si ricordi che se si rompe qualcosa nel proprio NMU, molte persone saranno molto scontente al riguardo.

• Come si e sicuri sulle modifiche? Si ricorda il giuramento di Ippocrate: "Soprattutto, non nuocere". E' meglio lasciare un pacchetto con un grave bug aperto che applicare una patch non funzionante, o uno che nasconde il bug invece di risolverlo. Se non si è sicuri al 100% di quello che si è fatto, potrebbe essere una buona idea chiedere il parere di altri. Ricordate che se si rompe qualcosa nel proprio NMU, molte persone saranno molto infelici di questo.

• Have you clearly expressed your intention to NMU, at least in the BTS? If that didn't generate any feedback, it might also be a good idea to try to contact the maintainer by other means (email to the maintainer addresses or private email, IRC).

• Se il maintainer è in genere attivo e reattivo, si è provato a contattarlo? Generalmente, dovrebbe essere considerato preferibile che i maintainer si prendano cura di un problema essi stessi e che abbiano la possibilità di rivedere e correggere la patch, in quanto sono più consapevoli dei potenziali problemi che un autore di NMU potrebbe non considerare. Spesso è un miglior uso del tempo di tutti se al maintainer viene data la possibilità di caricare una propria soluzione.

Nel fare un NMU, è necessario assicurarsi che la propria intenzione di un NMU sia chiara. Quindi, è necessario inviare una patch al BTS con le differenze tra il pacchetto attuale e il proprio NMU. Lo script nmudiff nel pacchetto devscripts potrebbe essere utile.

While preparing the patch, you had better be aware of any package-specific practices that the maintainer might be using. Taking them into account reduces the burden of integrating your changes into the normal package workflow and thus increases the chances that integration will happen. A good place to look for possible package-specific practices is debian/README.source.

A meno che non si disponga di un ottimo motivo per non farlo, è necessario quindi dare un po' di tempo al maintainer per reagire (per esempio, caricandolo nella coda DELAYED). Ecco alcuni valori consigliati da usare nei casi differiti:

• Caricamento che risolve solo bug critici per il rilascio più vecchi di 7 giorni, senza alcuna attività del maintainer sul bug per 7 giorni e nessuna indicazione che si stia lavorando ad una soluzione: 0 giorni

• Caricamento che risolve solo bug critici per il rilascio più vecchi di 7 giorni: 2 giorni

• Caricamento che risolve solo bug critici per il rilascio e per bug importanti: 5 giorni

• Altri NMU: 10 giorni

Tali ritardi sono solo degli esempi. In alcuni casi, come ad esempio caricamenti di correzioni di problemi di sicurezza o di correzioni di bug banali che bloccano una transizione, è auspicabile che il pacchetto corretto raggiunga prima unstable.

Sometimes, release managers decide to encourage NMUs with shorter delays for a subset of bugs (e.g release-critical bugs older than 7 days). Also, some maintainers list themselves in the Low Threshold NMU list, and accept that NMUs are uploaded without delay. But even in those cases, it's still a good idea to give the maintainer a few days to react before you upload, especially if the patch wasn't available in the BTS before, or if you know that the maintainer is generally active.

Dopo aver caricato un NMU, si è responsabili per i possibili problemi che si potrebbe avere introdotto. È necessario tenere d'occhio il pacchetto (iscriversi al pacchetto sul PTS è un buon modo per raggiungere questo obiettivo).

Questa non è una licenza per eseguire NMU in modo sconsiderato. Se si effettua un NMU quando è chiaro che i maintainer sono attivi e avrebbero preso in considerazione una patch tempestivamente, oppure se si ignorano le raccomandazioni di questo documento, il caricamento potrebbe essere causa di conflitto con il maintainer. Si dovrebbe sempre essere pronti a difendere la saggezza di ogni NMU che si fa sulla base dei suoi meriti.

5.11.2. NMU e debian/changelog

Just like any other (source) upload, NMUs must add an entry to debian/changelog, telling what has changed with this upload. The first line of this entry must explicitly mention that this upload is an NMU, e.g.:

* Non-maintainer upload.

Il modo di assegnare versioni agli NMU è differente per i pacchetti nativi e per i non-nativi.

Se il pacchetto è un pacchetto nativo (senza una revisione Debian nel numero di versione), la versione deve essere la versione dell'ultimo caricamento del maintainer, più +nmuX, dove X è un contatore a partire 1. Se anche l'ultimo caricamento è stato un NMU, il contatore dovrebbe essere aumentato. Ad esempio, se la versione corrente è 1.5, allora un NMU avrebbe la versione 1.5+nmu1.

Se il pacchetto non è un pacchetto nativo, si dovrebbe aggiungere un numero di versione secondario alla parte di revisione Debian del numero di versione (la parte dopo l'ultimo trattino). Questo numero aggiuntivo deve iniziare da 1. Ad esempio, se la versione corrente è 1.5-2, poi un NMU otterrebbe la versione 1.5-2.1. Se nell'NMU viene pacchettizzata una nuova versione a monte, la revisione Debian viene impostata a 0, per esempio 1.6-0.1.

In entrambi i casi, se anche l'ultimo caricamento è stato un NMU, il contatore dovrebbe essere aumentato. Ad esempio, se la versione corrente è 1.5+nmu3 (un pacchetto nativo che ha già subito un NMU), l'NMU avrebbe versione 1.5+nmu4.

Uno speciale schema per i nomi di versione del codice è necessario per evitare di danneggiare il lavoro del maintainer, in quanto utilizzare un numero intero per la revisione Debian potenzialmente potrebbe entrare in conflitto con un caricamento del maintainer già in preparazione al momento di un NMU, o anche con uno presente nella coda NEW dell'ftp. Ha anche il vantaggio di rendere visivamente chiaro che un pacchetto nell'archivio non è stato fatto dal maintainer ufficiale.

Se si carica un pacchetto su testing o stable, a volte è necessario fare il «fork» dell'albero dei numeri di versione. Questo è il caso dei caricamenti di sicurezza, ad esempio. Per questo dovrebbe essere usata una versione della forma +debXYuZ, dove X e Y sono i numeri di versione principale e minore, e Z è un contatore che parte da 1. Quando il numero di rilascio non è ancora noto (spesso è il caso per testing, all'inizio dei cicli di rilascio), deve essere utilizzato il più basso numero di versione che è più alto dell'ultimo numero di rilascio stabile. Per esempio, mentre Lenny (Debian 5.0) è stabile, un NMU di sicurezza a stable per un pacchetto alla versione 1.5-3 avrebbe versione 1.5-3+deb50u1, mentre un NMU di sicurezza per Squeeze avrebbe versione 1.5-3+deb60u1. Dopo l'uscita di Squeeze, i caricamenti di sicurezza per la distribuzione testing saranno avranno versione +deb61uZ, fino a quando non è noto se tale versione sarà Debian 6.1 o Debian 7.0 (se si avvera quest'ultimo caso i caricamenti avranno versione come +deb70uZ).

5.11.3. Utilizzare la coda DELAYED/

Il dover attendere una risposta dopo che si è richiesto il permesso per un NMU è inefficiente, perché costa all'autore dell'NMU un cambio di contesto per ritornare sul problema. La coda DELAYED (si consulti Caricamenti differiti) consente allo sviluppatore che fa l'NMU di svolgere al tempo stesso tutti i compiti necessari. Per esempio, invece di dire al maintainer che si caricherà il pacchetto aggiornato tra 7 giorni, si dovrebbe caricare il pacchetto in DELAYED/7 e dire al maintainer che ha 7 giorni di tempo per reagire. Durante questo tempo, il maintainer può chiedere di ritardare il caricamento di un po', o annullarlo.

You can cancel your upload using dcut. In case you uploaded foo_1.2-1.1_all.changes to a DELAYED queue, you can run dcut cancel foo_1.2-1.1_all.changes to cancel your upload. The .changes file does not need to be present locally as you instruct dcut to upload a command file removing a remote filename. The .changes file name is the same that you used when uploading.

La coda DELAYED non deve essere utilizzata per mettere ulteriore pressione sul maintainer. In particolare, è importante che ci si renda disponibili ad annullare o ritardare il caricamento prima della scadenza del ritardo in quanto il maintainer non lo può annullare da solo.

Se si fa un NMU DELAYED e il maintainer aggiorna il pacchetto prima della scadenza del ritardo, il caricamento sarà respinto perché una nuova versione è già disponibile nell'archivio. Idealmente, il maintainer avrà cura di includere in questa versione le modifiche proposte (o almeno una soluzione per i problemi che affrontano).

5.11.4. NMU dal punto di vista del maintainer

Quando qualcuno fa un NMU per il vostro pacchetto, questo significa che vuole aiutare a mantenerlo in buona forma. Questo dà agli utenti più velocemente dei pacchetti corretti. Si può considerare di chiedere all'autore dell'NMU di diventare un co-maintainer del pacchetto. La ricezione di un NMU su un pacchetto non è una cosa negativa; ma semplicemente significa che il pacchetto è abbastanza interessante per le altre persone da spingerle a lavorare su di esso.

Per riconoscere un NMU, si includano i suoi cambiamenti e le voci del changelog nel proprio prossimo caricamento da maintainer. Se non si riconosce l'NMU non includendo le voci del changelog dell'NMU nel proprio changelog, i bug rimarranno chiusi nel BTS, ma saranno elencati come presenti nella propria versione di maintainer del pacchetto.

Note that if you ever need to revert a NMU that packages a new upstream version, it is recommended to use a fake upstream version like CURRENT+reallyFORMER until one can upload the latest version again. More information can be found in https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly.

5.11.5. Source NMUs vs Binary-only NMUs (binNMUs)

Il nome completo di un NMU è NMU sorgente. C'è anche un altro tipo, vale a dire la NMU solo binario, o binNMU. Un binNMU è anche un pacchetto caricato da una persona diversa dal maintainer del pacchetto. Tuttavia, è un solo un caricamento dei soli binari.

Quando una libreria (o altra dipendenza) viene aggiornata, i pacchetti che la utilizzano possono aver bisogno di essere ricompilati. Dal momento che non sono necessarie modifiche al sorgente, viene utilizzato lo stesso pacchetto sorgente.

I binNMU sono di solito attivati sui buildd da wanna-build. Viene aggiunta una voce al debian/changelog, che spiega perché il caricamento è stato necessario e incrementa il numero di versione come descritto in Ricompilazione o NMU dei soli binari. Questa voce non deve essere inclusa nel prossimo caricamento.

Buildds carica i pacchetti per le loroarchitetture negliarchivi come upload binari. Parlando più precisamente, questi sono binNMUs. Comunque, non sono chimamati NMU, e non sono aggiunte voci al debian/changelog.

5.11.6. NMU e caricamenti di QA

NMUs are uploads of packages by somebody other than their assigned maintainer. There is another type of upload where the uploaded package is not yours: QA uploads. QA uploads are uploads of orphaned packages.

I caricamenti di QA sono molto simili a normali caricamenti del maintainer: possono correggere qualsiasi cosa, anche problemi minori; la numerazione delle versioni è normale, e non vi è alcuna necessità di utilizzare un caricamento differito. La differenza è che non si viene elencati come il Maintainer o Uploader per il pacchetto. Inoltre, la voce del changelog del caricamento di QA ha una speciale prima riga:

* QA upload.

Se si vuole fare un NMU, e sembra che il maintainer non sia attivo, è consigliabile controllare se il pacchetto sia orfano (questa informazione viene visualizzata sulla pagina Package Tracking System del pacchetto). Quando si fa il primo caricamento di QA ad un pacchetto orfano, il maintainer deve essere impostato su Debian QA Group <packages@qa.debian.org>. I pacchetti orfani che non avevano ancora un caricamento QA hanno ancora indicato il loro vecchio maintainer. C'è un elenco di questi ultimi in https://qa.debian.org/orphaned.html.

Instead of doing a QA upload, you can also consider adopting the package by making yourself the maintainer. You don't need permission from anybody to adopt an orphaned package; you can just set yourself as maintainer and upload the new version (see L'adozione di un pacchetto).

5.11.7. NMU e caricamenti del team

Sometimes you are fixing and/or updating a package because you are member of a packaging team (which uses a mailing list as Maintainer or Uploader; see La manutenzione collaborativa) but you don't want to add yourself to Uploaders because you do not plan to contribute regularly to this specific package. If it conforms with your team's policy, you can perform a normal upload without being listed directly as Maintainer or Uploader. In that case, you should start your changelog entry with the following line:

* Team upload.

5.12. Package Salvaging

Package salvaging is the process by which one attempts to save a package that, while not officially orphaned, appears poorly maintained or completely unmaintained. This is a weaker and faster procedure than orphaning a package officially through the powers of the MIA team. Salvaging a package is not meant to replace MIA handling, and differs in that it does not imply anything about the overall activity of a maintainer. Instead, it handles a package maintainership transition for a single package only, leaving any other package or Debian membership or upload rights (when applicable) untouched.

Note that the process is only intended for actively taking over maintainership. Do not start a package salvaging process when you do not intend to maintain the package for a prolonged time. If you only want to fix certain things, but not take over the package, you must use the NMU process, even if the package would be eligible for salvaging. The NMU process is explained in Caricamenti dei Non-Maintainer (NMU).

Another important thing to remember: It is not acceptable to hijack others' packages. If followed, this salvaging process will help you to ensure that your endeavour is not a hijack but a (legal) salvaging procedure, and you can counter any allegations of hijacking with a reference to this process. Thanks to this process, new contributors should no longer be afraid to take over packages that have been neglected or entirely forgotten.

The process is split into two phases: In the first phase you determine whether the package in question is eligible for the salvaging process. Only when the eligibility has been determined you may enter the second phase, the actual package salvaging.

For additional information, rationales and FAQs on package salvaging, please visit the Salvaging Packages page on the Debian wiki.

5.12.1. When a package is eligible for package salvaging

A package becomes eligible for salvaging when it has been neglected by the current maintainer. To determine that a package has really been neglected by the maintainer, the following indicators give a rough idea what to look for:

• NMUs, especially if there has been more than one NMU in a row.

• Bugs filed against the package do not have answers from the maintainer.

• Upstream has released several versions, but despite there being a bug entry asking for it, it has not been packaged.

• There are QA issues with the package.

You will have to use your judgement as to whether a given combination factors constitutes neglect; in case the maintainer disagrees they have only to say so (see below). If you're not sure about your judgement or simply want to be on the safe side, there is a more precise (and conservative) set of conditions in the Package Salvaging wiki page. These conditions represent a current Debian consensus on salvaging criteria. In any case you should explain your reasons for thinking the package is neglected when you file an Intent to Salvage bug later.

5.12.2. How to salvage a package

If and only if a package has been determined to be eligible for package salvaging, any prospective maintainer may start the following package salvaging procedure.

1. Open a bug with the severity "important" against the package in question, expressing the intent to take over maintainership of the package. For this, the title of the bug should start with ITS: package-name [3]. You may alternatively offer to only take co-maintenance of the package. When you file the bug, you must inform all maintainers, uploaders and if applicable the packaging team explicitly by adding them to X-Debbugs-CC. Additionally, if the maintainer(s) seem(s) to be generally inactive, please inform the MIA team by adding mia@qa.debian.org to X-Debbugs-CC as well. As well as the explicit expression of the intent to salvage, please also take the time to document your assessment of the eligibility in the bug report, for example by listing the criteria you've applied and adding some data to make it easier for others to assess the situation.

2. In this step you need to wait in case any objections to the salvaging are raised; the maintainer, any current uploader or any member of the associated packaging team of the package in question may object publicly in response to the bug you've filed within 21 days, and this terminates the salvaging process.

   The current maintainers may also agree to your intent to salvage by filing a (signed) public response to the the bug. They might propose that you become a co-maintainer instead of the sole maintainer. On team maintained packages, a member of the associated team can accept your salvaging proposal by sending out a signed agreement notice to the ITS bug, alternatively inviting you to become a new co-maintainer of the package. The team may require you to keep the package under the team's umbrella, but then may ask or invite you to join the team. In any of these cases where you have received the OK to proceed, you can upload the new package immediately as the new (co-)maintainer, without the need to utilise the DELAYED queue as described in the next step.

3. After the 21 days delay, if no answer has been sent to the bug from the maintainer, one of the uploaders or team, you may upload the new release of the package into the DELAYED queue with a minimum delay of seven days. You should close the salvage bug in the changelog and you must also send an nmudiff to the bug ensuring that copies are sent to the maintainer and any uploaders (including teams) of the package by CC'ing them in the mail to the BTS.

   During the waiting time of the DELAYED queue, the maintainer can accept the salvaging, do an upload themselves or (ask to) cancel the upload. The latter two of these will also stop the salvaging process, but the maintainer must reply to the salvaging bug with more information about their action.

5.13. La manutenzione collaborativa

Manutenzione collaborativa è un termine che descrive la condivisione dei compiti di manutenzione dei pacchetti Debian tra più persone. Questa collaborazione è quasi sempre una buona idea, dato che in genere si traduce in una maggiore qualità e in tempi più rapidi per la soluzione di bug. Si raccomanda vivamente che i pacchetti con priorità standard o che sono parte dell'insieme base abbiano dei co-maintainer.

In generale vi è un maintainer primario e uno o più co-maintainer. Il maintainer primario è la persona il cui nome è inserito nel campo Maintainer del file debian/control. Co-maintainer sono tutti gli altri maintainer, di solito elencati nel campo Uploaders del file debian/control.

Nella sua forma più semplice, il processo di aggiunta di un nuovo co-maintainer è abbastanza facile:

• Set up the co-maintainer with access to the sources you build the package from. Generally this implies you are using a network-capable version control system, such as Git. Salsa (see salsa.debian.org: Git repositories and collaborative development platform) provides Git repositories, amongst other collaborative tools.

• Si aggiunga il nome corretto del co-maintainer e l'indirizzo nel campo Uploaders nel primo paragrafo del file debian/control.

  Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
  

• Si utilizzi il PTS (The Debian Package Tracker), i co-maintainer dovrebbero iscriversi all'appropriato pacchetto di sorgenti.

Un'altra forma di manutenzione collaborativa è la manutenzione in un team, che è raccomandata se si mantengono diversi pacchetti con lo stesso gruppo di sviluppatori. In tal caso, i campi Maintainer e Uploaders di ogni pacchetto devono essere gestiti con attenzione. Si consiglia di scegliere tra i seguenti due schemi:

1. Inserire il membro del team che è il principale responsabile per il pacchetto nel campo Maintainer. Nel campo Uploaders, inserire l'indirizzo della mailing list, ed i membri del team che si interessano al pacchetto.

2. Put the mailing list address in the Maintainer field. In the Uploaders field, put the team members who care for the package. In this case, you must make sure the mailing list accepts bug reports without any human interaction (like moderation for non-subscribers).

In ogni caso, è una cattiva idea mettere automaticamente tutti i membri del team nel campo Uploaders. Ciò ingombra l'elenco dei Developer's Package Overview (si consulti Panoramica dei pacchetti per sviluppatori) con pacchetti di cui di fatto uno non si occupa veramente, e crea un falso senso di buona manutenzione. Per lo stesso motivo, i membri del team non devono di aggiungere se stessi nel campo Uploaders solo perché stanno caricando il pacchetto una sola volta, possono fare un «caricamento di Team» (si consulti NMU e caricamenti del team). Al contrario, è una cattiva idea tenere un pacchetto con il solo indirizzo della mailing list come Maintainer e senza nessuno Uploaders.

5.14. La distribuzione testing

5.14.1. Nozioni di base

I pacchetti sono generalmente installati nella distribuzione testing dopo aver subito un periodo di prova in unstable.

Essi devono essere sincronizzati su tutte le architetture e non devono avere dipendenze tali da renderli non installabili; inoltre devono generalmente non avere bug critici per il rilascio noti nel momento dell'installazione in testing. In questo modo, testing dovrebbe essere sempre vicina ad essere candidata al rilascio. Si veda sotto per i dettagli.

5.14.2. Aggiornamenti da unstable

Gli script che aggiornano la distribuzione testing vengono eseguiti due volte al giorno, subito dopo l'installazione dei pacchetti aggiornati; questi script si chiamano britney. Essi generano i file Packages per la distribuzione testing, ma lo fanno in modo intelligente; cercano di evitare qualsiasi incoerenza e di utilizzare solo i pacchetti senza bug.

L'inclusione di un pacchetto da unstable è subordinata alle seguenti:

• The package must have been available in unstable for a certain number of days, see Selecting the upload urgency. Please note that the urgency is sticky, meaning that the highest urgency uploaded since the previous testing transition is taken into account;

• Non deve avere nuovi bug critici per il rilascio (bug RC che riguardano la versione disponibile in unstable, ma non intaccano la versione in testing);

• Deve essere disponibile su tutte le architetture sulle quali è stato precedentemente compilato in unstable. L'utility dak ls può essere utile per verificare queste informazioni;

• Non deve rendere diffettosa alcuna dipendenza di un pacchetto che è già disponibile in testing;

• I pacchetti da cui dipende devono essere disponibili in testing o devono essere accettati in testing nello stesso momento (e lo saranno se soddisfano tutti i criteri necessari);

• La fase del progetto. Cioè transizioni automatiche sono disattivate durante il freeze della distribuzione testing.

Per sapere se un pacchetto è in fase di passaggio a testing o meno, si consulti il prodotto dello script di testing nella pagina web della distribuzione testing, oppure si utilizzi il programma grep-excuses, che è nel pacchetto devscripts. Questa utility può essere facilmente utilizzata in un crontab5 per tenersi informati sull'avanzamento dei propri pacchetti in testing.

Il file update_excuses non sempre dà il motivo preciso per cui il pacchetto è stato rifiutato; potrebbe essere necessario trovarlo da soli, cercando ciò che sarebbe stato reso difettoso dall'inclusione. La pagina web di testing dà qualche informazione in più sulle problematiche comuni che possono causare questi problemi.

A volte, alcuni pacchetti non entrano mai in testing, perché l'insieme di interrelazioni è troppo complicato e non può essere risolto dagli script. Si veda sotto per i dettagli.

Some further dependency analysis is shown on https://release.debian.org/migration/ — but be warned: this page also shows build dependencies that are not considered by britney.

5.14.2.1. Obsoleti

For the testing migration script, outdated means: There are different versions in unstable for the release architectures (except for the architectures in outofsync_arches; outofsync_arches is a list of architectures that don't keep up (in britney.py), but currently, it's empty). Outdated has nothing whatsoever to do with the architectures this package has in testing.

Si consideri questo esempio:

	alpha	arm
testing	1	-
unstable	1	2

The package is out of date on alpha in unstable, and will not go to testing. Removing the package would not help at all; the package is still out of date on alpha, and will not propagate to testing.

Tuttavia, se l'ftp-master rimuove un pacchetto in unstable (qui in arm):

	alpha	arm	hurd-i386
testing	1	1	-
unstable	2	-	1

In questo caso, il pacchetto è aggiornato su tutte le architetture di rilascio in unstable (e quella aggiuntiva hurd-i386 non importa, considerato che non è un'architettura inclusa nel rilascio).

A volte, la questione che viene sollevata è se è possibile far avanzare pacchetti che non sono ancora stati compialti su tutte le architetture: No. Sempre e comunque no. (Tranne se si mantiene glibc o giù di lì.)

5.14.2.2. Rimozioni da testing

A volte, un pacchetto viene rimosso per consentire ad un altro pacchetto di entrare: questo accade solo per permettere ad un altro pacchetto di avanzare se è pronto sotto ogni altro aspetto. Supponiamo ad esempio che a non può essere installato con la nuova versione di b; allora a può essere rimosso per consentire a b di entrare.

Of course, there is another reason to remove a package from testing: it's just too buggy (and having a single RC-bug is enough to be in this state).

Inoltre, se un pacchetto è stato rimosso da unstable, e nessun pacchetto in testing dipende più da esso, allora sarà automaticamente rimosso.

5.14.2.3. Dipendenze circolari

Una situazione che non è gestita molto bene da britney è se un pacchetto a dipende dalla nuova versione del pacchetto b, e viceversa.

Un esempio di questo è:

	testing	unstable
a	1; depends: b=1	2; depends: b=2
b	1; depends: a=1	2; depends: a=2

Né il pacchetto a, né il pacchetto b sono considerati per l'aggiornamento.

Attualmente, questo richiede qualche suggerimento manuale al team di rilascio. contattarli con l'invio di una email a debian-release@lists.debian.org se ciò dovesse accadere ad uno dei propri pacchetti.

5.14.2.4. Influenza del pacchetto in testing

Generally, there is nothing that the status of a package in testing means for transition of the next version from unstable to testing, with two exceptions: If the RC-bugginess of the package goes down, it may go in even if it is still RC-buggy. The second exception is if the version of the package in testing is out of sync on the different arches: Then any arch might just upgrade to the version of the source package; however, this can happen only if the package was previously forced through, the arch is in outofsync_arches, or there was no binary package of that arch present in unstable at all during the testing migration.

In sintesi questo significa: l'unica influenza che un pacchetto presente in testing ha su una nuova versione dello stesso pacchetto è che la nuova versione potrebbe entrarci più facilmente.

5.14.2.5. Dettagli

Se si è interessati a maggiori dettagli, cosi è come funziona britney:

I pacchetti sono osservati per determinare se essi sono validi candidati. Da questo derivano le motivazioni per gli aggiornamenti. Le ragioni più comuni per cui un pacchetto non viene considerato essere troppo giovane, mancanza di bug RC, e obsoleto su alcune architetture. Per questa parte di britney, i gestori dei rilasci posseggono martelli di varie dimensioni, chiamati suggerimenti (si consulti sotto), per forzare britney a considerare un pacchetto.

Ora arriva la parte più complessa: britney tenta di aggiornare testing con i candidati validi. Per questo, britney cerca di aggiungere ogni candidato valido per la distribuzione testing. Se il numero di pacchetti non installabili in testing non aumenta, il pacchetto viene accettato. Da quel momento in poi, il pacchetto viene considerato parte di testing, in modo che tutti i test di installabilità successivi includeranno questo pacchetto. Suggerimenti da parte del team di rilascio vengono elaborati prima o dopo questo ciclo principale, a seconda del tipo esatto.

If you want to see more details, you can look it up on https://release.debian.org/britney/update_output/.

The hints are available via https://release.debian.org/britney/hints/, where you can find the description as well. With the hints, the Debian Release team can block or unblock packages, ease or force packages into testing, remove packages from testing, approve uploads to Aggiornamenti diretti di testing or override the urgency.

5.14.3. Aggiornamenti diretti di testing

La distribuzione testing è alimentata con i pacchetti da unstable in base alle regole sopra esposte. Tuttavia, in alcuni casi, è necessario caricare i pacchetti compilati solo per testing. Per questo, è meglio fare il caricamento in testing-proposed-updates.

Keep in mind that packages uploaded there are not automatically processed; they have to go through the hands of the release manager. So you'd better have a good reason to upload there. In order to know what a good reason is in the release managers' eyes, you should read the instructions that they regularly give on debian-devel-announce@lists.debian.org.

You should not upload to testing-proposed-updates when you can update your packages through unstable. If you can't (for example because you have a newer development version in unstable), you may use this facility. Even if a package is frozen, updates through unstable are possible, if the upload via unstable does not pull in any new dependencies.

I numeri della versione sono solitamente individuati concatenando +debXuY, dove X è il numero maggiore della release Debian e Y è un contatore che inizia da 1. e.s.1:2.4.3-4+deb12u1.

Assicurarsi di non essersi dimenticata nessuna di queste cose nel proprio caricamento:

• Assicurarsi che il proprio pacchetto abbia davvero bisogno di passare attraverso testing-proposed-updates, e non possa passare attraverso unstable;

• Assicurarsi di includere solo la quantità minima di modifiche;

• Assicurarsi di aver incluso una spiegazione adeguata nel changelog;

• Make sure that you've written the testing Nomi in codice dei rilasci (e.g. trixie) into your target distribution;

• Assicurarsi di aver compilato e testato il proprio pacchetto in testing, non in unstable;

• Assicurarsi che il numero di versione sia più alto rispetto alla versione in testing e in testing-proposed-updates, e inferiore a quello in unstable;

• Ask for authorization for uploading from the release managers.

• Dopo aver effettuato il caricamento e dopo che la compilazione è riuscita su tutte le piattaforme, si contatti il team di rilascio su debian-release@lists.debian.org chiedendogli di approvare il caricamento.

5.14.4. Domande frequenti

5.14.4.1. Quali sono i bug critici per il rilascio e come vengono contati?

Tutti i bug di alcuni livelli più elevati di gravità sono di base considerati release-critical; attualmente, questi sono i bug critical, grave e serious.

Tali bug sono ritenuti avere un impatto sulle possibilità che il pacchetto venga rilasciato con la distribuzione stable di Debian: in generale, se un pacchetto ha un bug critico per il rilascio aperto, non sarà integrato in testing, e di conseguenza non sarà rilasciato in stable.

The unstable bug count comprises all release-critical bugs that are marked to apply to package/version combinations available in unstable for a release architecture. The testing bug count is defined analogously.

5.14.4.2. Come potrebbe l'installazione di un pacchetto in testing rendere difettosi altri pacchetti?

La struttura degli archivi di distribuzione è tale che possono contenere solo una versione di un pacchetto; un pacchetto è definito dal suo nome. Così, quando il pacchetto sorgente acmefoo è installato in testing, insieme con i suoi pacchetti binari acme-foo-bin, acme-bar-bin, libacme-foo1 e libacme-foo-dev, la versione precedente viene rimossa.

However, the old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages that depend on it.

Evidently, this mainly affects packages that provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.

When the set of binary packages provided by a source package changes in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into testing breaks all the packages that depended on it in testing, some care has to be taken now: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.

Se si hanno problemi con gruppi complessi di pacchetti come questo, si contatti debian-devel@lists.debian.org o debian-release@lists.debian.org per un aiuto.

[1]

Si consulti il Debian Policy Manual per le linee guida su quale sezione appartiene un pacchetto.

[2]

In passato, tali NMU utilizzarono il numero di terzo livello della parte della revisione di Debian per indicare solo la loro ricompilazione; tuttavia, questa sintassi era ambigua con i pacchetti nativi e non ha permesso una corretta ordinazione delle sole ricompilazioni NMU, NMU sorgente, e NMU di sicurezza sullo stesso package, ed è stata abbandonata in favore di questa nuova sintassi.

[3]

ITS is shorthand for "Intend to Salvage"

[4]

Though, if a package still is in the upload queue and hasn't been moved to Incoming yet, it can be removed. (see Caricamento su ftp-master)

5.15. The Stable backports archive

5.15.1. Nozioni di base

Once a package reaches the testing distribution, it is possible for anyone with upload rights in Debian (see below about this) to build and upload a backport of that package to stable-backports, to allow easy installation of the version from testing onto a system that is tracking the stable distribution.

One should not upload a version of a package to stable-backports until the matching version has already reached the testing archive.

5.15.2. Exception to the testing-first rule

The only exception to the above rule, is when there's an important security fix that deserves a quick upload: in such a case, there is no need to delay an upload of the security fix to the stable-backports archive. However, it is strongly advised that the package is first fixed in unstable before uploading a fix to the stable-backports archive.

5.15.3. Who can maintain packages in the stable-backports archive?

It is not necessarily up to the original package maintainer to maintain the stable-backports version of the package. Anyone can do it, and one doesn't even need approval from the original maintainer to do so. It is however good practice to first get in touch with the original maintainer of the package before attempting to start the maintenance of a package in stable-backports. The maintainer can, if they wish, decide to maintain the backport themselves, or help you doing so. It is not uncommon, for example, to apply a patch to the unstable version of a package, to facilitate its backporting.

5.15.4. When can one start uploading to stable-backports?

The new stable-backports is created before the freeze of the next stable suite. However, it is not allowed to upload there until the very end of the freeze cycle. The stable-backports archive is usually opened a few weeks before the final release of the next stable suite, but it doesn't make sense to upload until the release has actually happened.

5.15.5. How long must a package be maintained when uploaded to stable-backports?

The stable-backports archive is maintained for bugs and security issues during the whole life-cycle of the Debian stable suite. Therefore, an upload to stable-backports, implies a willingness to maintain the backported package for the duration of the stable suite, which can be expected to be about 3 years from its initial release.

The person uploading to backports is also supposed to maintain the backported packages for security during the lifetime of stable.

It is to be noted that the stable-backports isn't part of the LTS or ELTS effort. The stable-backports FTP masters will close the stable-backports repositories for uploads once stable reaches end-of-life (ie: when stable becomes maintained by the LTS team only). Therefore there won't be any maintenance of packages from stable-backports after the official end of life of the stable suite, as uploads will not be accepted.

5.15.6. How often shall one upload to stable-backports?

The packages in backports are supposed to follow the developments that are happening in Testing. Therefore, it is expected that any significant update in testing should trigger an upload into stable-backports, until the new stable is released. However, please do not backport minor version changes without user visible changes or bugfixes.

5.15.7. How can one learn more about backporting?

You can learn more about how to contribute directly on the backport web site.

It is also recommended to read the Frequently Asked Questions (FAQ).