[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ successivo ]


Guida per il nuovo Maintainer
Capitolo 4 - File richiesti nella directory debian


C'è una nuova sottodirectory all'interno della cartella contenente i sorgenti del programma ed è chiamata debian. All'interno di questa vi sono una serie di file che dovranno essere modificati per personalizzare il comportamento del pacchetto. I più importanti fra tutti questi sono i file control, changelog, copyright e rules, che vengono richiesti per tutti i pacchetti.


4.1 Il file control

Questo file contiene diversi valori che dpkg, dselect, apt-get, apt-cache, aptitude, ed altri strumenti utilizzeranno per gestire il pacchetto. Il tutto è definito nel Manuale delle policy di Debian, 5 'File di controllo e loro campi'.

Questo è il file di controllo che dh_make crea:

      1 Source: gentoo
      2 Section: unknown
      3 Priority: extra
      4 Maintainer: Josip Rodin <joy-mg@debian.org>
      5 Build-Depends: debhelper (>= 7.0.50~)
      6 Standards-Version: 3.8.4
      7 Homepage: <insert the upstream URL, if relevant>
      8
      9 Package: gentoo
     10 Architecture: any
     11 Depends: ${shlibs:Depends}, ${misc:Depends}
     12 Description: <insert up to 60 chars description>
     13  <insert long description, indented with spaces>

(Sono stati aggiunti i numeri di riga.)

Le righe 1-6 contengono informazioni di controllo per il pacchetto sorgente.

La riga 1 contiene il nome del pacchetto sorgente.

La riga 2 indica la sezione della distribuzione in cui il pacchetto sorgente dovrà andare.

Come si sarà notato, l'archivio Debian è diviso in sezioni: main (software libero), non-free (software non propriamente libero) e contrib (software libero che dipende da software non libero). All'interno di queste esistono delle sottosezioni che descrivono brevemente quali pacchetti vi si possono trovare. Quindi si hanno le sezioni admin per i programmi legati all'amministrazione di sistema, base per gli strumenti di base, devel per gli strumenti di sviluppo, doc per la documentazione, libs per le librerie, mail per client di posta e server associati, net per applicazioni e servizi di rete, x11 per programmi X11 che non appartengono alle altre categorie, e tanti altri. Si legga Manuale delle policy di Debian, 2.4 'Sezioni' e List of sections in 'sid' per maggiori informazioni.

Si può quindi cambiare il valore alla seconda riga in x11. (Il prefisso main/ è implicito e può essere omesso.)

La riga numero 3 indica quanto sia importante per l'utente installare questo pacchetto. Si legga Manuale delle policy di Debian, 2.5 'Priorità' per maggiori informazioni.

Le sezioni e le priorità vengono solitamente utilizzate da interfacce come aptitude in cui i pacchetti vengono suddivisi e vengono selezionati quelli predefiniti. Una volta caricato il pacchetto in Debian, il valore di ciascuno di questi due campi può essere sovrascritto dai manutentori dell'archivio, in tal caso si verrà avvertiti via mail.

Dal momento che il pacchetto trattato ha una priorità normale e non va in conflitto con altri, si cambierà la priorità a "optional".

La riga 4 indica il nome e l'indirizzo email del manutentore. Ci si assicuri che questo campo includa una testata "To" valida per un indirizzo mail, perché una volta caricato il pacchetto, il sistema di rilevazione bug la userà per inviare le mail contenenti i bug. Si eviti di utilizzare virgole, 'e' commerciali e parentesi.

La quinta linea include la lista dei pacchetti richiesti per costruire il pacchetto, ad es. il campo Build-Depends. Si può, inoltre, avere una riga contenente il campo Build-Depends-Indep. (vedere il Manuale delle policy di Debian, 7.7 'Relazione tra pacchetti sorgenti e binari - Build-Depends, Build-Depends-Indep, Build-Conflicts, Build-Conflicts-Indep'). Alcuni pacchetti come gcc e make sono richiesti implicitamente, dal pacchetto build-essential. Se si ha la necessità di avere altri strumenti per costruire il pacchetto, questi devono essere aggiunti negli appositi campi. I campi multipli sono separati con le virgole; si legga una spiegazione sulle dipendenze binarie per scoprirne di più sulla sintassi di queste righe.

Se non si è sicuri sul campo da utilizzare, si può scegliere il campo Build-Depends.[16]

Per scoprire di quali pacchetti si ha bisogno per la compilazione si può eseguire il comando:

     $ dpkg-depcheck -d ./configure

Per scoprire manualmente le esatte dipendenze per /usr/bin/foo, si esegue

     $ objdump -p /usr/bin/foo | grep NEEDED

e per ogni libreria elencata, ad esempio, libfoo.so.6, si esegue

     $ dpkg -S libfoo.so.6

A questo punto si indica la versione -dev di ogni pacchetto come voce Build-Depends. Se si usa ldd per questo scopo, verranno considerate anche le dipendenze indirette, il che potrà portare ad avere un numero eccessivo di dipendenze.

Il pacchetto gentoo richiede anche xlibs-dev, libgtk1.2-dev e libglib1.2-dev per poter essere costruito, quindi tali dipendenze si aggiungeranno subito dopo debhelper.

La riga 6 indica la versione delle delle linee guida Debian che il pacchetto deve rispettare, che corrisponde a quello che si legge quando lo si crea.

Nella riga 7 si può inserire l'URL della pagina del programma originale.

La riga 9 indica il nome del pacchetto binario. Questo è normalmente lo stesso nome del pacchetto sorgente, ma non deve essere necessariamente così.

Alla riga 10 viene descritta l'architettura CPU per cui può essere compilato il pacchetto binario. Si lascerà "any" perché dpkg-gencontrol(1) riempa questo campo con un valore adeguato per ciascuna macchina in cui il pacchetto viene compilato.

Se il pacchetto è indipendente dall'architettura (per esempio, uno script shell o Perl, o un documento), si cambi questo valore in "all", e si legga in seguito in Il file rules, Sezione 4.4 riguardo l'utilizzo della regola binary-indep al posto di binary-arch per costruire il pacchetto.

La riga 11 mostra una delle caratteristiche più potenti del sistema di pacchettizzazione Debian. Ovvero la possibilità di creare vari tipi di relazioni tra i pacchetti. A parte la già nota relazione Depends, le altre sono Recommends, Suggests, Pre-Depends, Conflicts, Provides, e Replaces.

Gli strumenti di gestione dei pacchetti solitamente si comportano allo stesso modo quando si occupano di tali relazioni; in caso contrario, il comportamento verrà spiegato. (si legga dpkg(8), dselect(8), apt(8), aptitude(1) ecc.)

Questo è il significato delle relazioni:

Tutti i campi qui descritti hanno una sintassi uniforme. Sono costituiti da una lista contenente i nomi dei pacchetti separati da virgole. Questi possono essere anche costituiti da liste di nomi di pacchetto alternativi, separati da barre verticali "|" (simboli pipe).

I campi possono limitare la loro applicabilità a particolari versioni di ogni pacchetto indicato. Queste versioni sono elencate tra parentesi dopo ogni singolo nome di pacchetto, e dovrebbero contenere una relazione presa dalla lista qui sotto seguita dal numero di versione. Le relazioni permesse sono: <<, <=, =, >= e >> per strettamente inferiore, inferiore o uguale, esattamente uguale, superiore o uguale e strettamente superiore, rispettivamente. Per esempio,

     Depends: foo (>= 1.2), libbar1 (= 1.3.4)
     Conflicts: baz
     Recommends: libbaz4 (>> 4.0.7)
     Suggests: quux
     Replaces: quux (<< 5), quux-foo (<= 7.6)

L'ultima caratteristica che si deve conoscere riguarda ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}, ecc. Queste voci sono sostituite dalle liste generate da altri componenti di debhelper quando il comando dh_gencontrol(1) viene eseguito.

dh_shlibdeps(1) farà la scansione alla ricerca di binari e librerie per determinare le loro dipendenze da altre librerie e individuare in quali pacchetti si trovano, come libc6 o xlib6g, dopo che il pacchetto sia stato costruito ed installato nella directory temporanea. Questa lista di dipendenze di libreria condivise è utilizzata per ${shlibs:Depends}.

La lista di pacchetti generata da dh_perl(1) viene utilizzata per ${perl:Depends}.

Alcuni comandi debhelper possono far si che il pacchetto generato abbia bisogno di dipendere da altri pacchetti. Questa lista di pacchetti richiesti è utilizzata per ${misc:Depends}.

Avendo detto ciò, si può lasciare la riga Depends esattamente come è ora, si può inserire un'altra riga dopo questa che dica "Suggests: file", perché gentoo può utilizzare alcune caratteristiche fornite dal pacchetto file.

La riga 12 contiene una breve descrizione del pacchetto. La maggioranza degli schermi degli utenti è larga 80 colonne quindi il contenuto non dovrebbe superare i 60 caratteri. Si cambia questo valore in "fully GUI-configurable, two-pane X file manager".

Nella riga 13 va messa la descrizione lunga. Questa dovrebbe consistere in un paragrafo che fornisce più dettagli sul pacchetto. La prima colonna di ogni riga dovrebbe essere vuota. Non ci dovrebbero essere linee vuote, ma si può mettere un singolo "." (punto) in una colonna per simularle. Inoltre non ci dovrebbe essere più di una linea vuota dopo questa descrizione.

Si inseriscono quindi i campi Vcs-* documentati su Developer's Reference, 6.2.5. 'Version Control System location' tra la linea 6 e 7. Si supponga che il pacchetto gentoo è posizionato nel Debian Alioth Git Service su git://git.debian.org/git/collab-maint/gentoo.git.

Infine, ecco come appare il file di controllo aggiornato:

      1 Source: gentoo
     
      2 Section: x11
     
      3 Priority: optional
     
      4 Maintainer: Josip Rodin <joy-mg@debian.org>
     
      5 Build-Depends: debhelper (>= 7.0.5), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
     
      6 Standards-Version: 3.8.4
     
      7 Vcs-Git: git://git.debian.org/git/collab-maint/gentoo.git
     
      8 Vcs-browser: http://git.debian.org/?p=collab-maint/gentoo.git
     
      9 Homepage: http://www.obsession.se/gentoo/
     
     10
     
     11 Package: gentoo
     
     12 Architecture: any
     
     13 Depends: ${shlibs:Depends}, ${misc:Depends}
     
     14 Suggests: file
     
     15 Description: fully GUI-configurable, two-pane X file manager
     
     16  gentoo is a two-pane file manager for the X Window System. gentoo lets the
     
     17  user do (almost) all of the configuration and customizing from within the
     
     18  program itself. If you still prefer to hand-edit configuration files,
     
     19  they're fairly easy to work with since they are written in an XML format.
     
     20  .
     
     21  gentoo features a fairly complex and powerful file identification system,
     
     22  coupled to a object-oriented style system, which together give you a lot
     
     23  of control over how files of different types are displayed and acted upon.
     
     24  Additionally, over a hundred pixmap images are available for use in file
     
     25  type descriptions.
     
     26  .
     
     29  gentoo was written from scratch in ANSI C, and it utilises the GTK+ toolkit
     
     30  for its interface.

(Sono stati aggiunti i numeri di riga.)


4.2 Il file copyright

Questo file contiene le informazioni sulle risorse del pacchetto, il copyright e la licenza. Il suo formato non è definito dal Manuale delle policy di Debian, ma il contenuto si trova in (Manuale delle policy di Debian, 12.5 'Informazioni di copyright'). Si può anche consultare DEP-5: Machine-parseable debian/copyright.

dh_make può fornire un modello di file del copyright, basta utilizzare l'opzione --copyright per selezionare quello giusto, se si desidera rilasciare il pacchetto gentoo sotto licenza GPL-2.

Si devono inserire le informazioni mancanti per completare questo file, come la fonte utilizzata per recuperare il pacchetto, le informazioni attuali di copyright e la licenza. Per le licenze più comuni relative al software libero come, GNU GPL-1, GNU GPL-2, GNU GPL-3, LGPL-2, LGPL-2.1, LGPL-3, GNU FDL-1.2, GNU FDL-1.3, Apache-2.0 o la licenza Artistic, è possibile fare riferimento al file appropriato nella directory /usr/share/common-licenses/ presente su ogni sistema Debian. In alternativa è necessario includere la licenza completa.

Brevemente, ecco come il file di copyright del pacchetto gentoo dovrebbe apparire:

      1 Format-Specification: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
     
      2 Name: gentoo
     
      3 Maintainer: Josip Rodin <joy-mg@debian.org>
     
      4 Source: http://sourceforge.net/projects/gentoo/files/
     
      5
     
      6 Copyright: 1998-2010 Emil Brink <emil@obsession.se>
     
      7 License: GPL-2+
     
      8
     
      9 Files: icons/*
     
     10 Copyright: 1998 Johan Hanson <johan@tiq.com>
     
     11 License: GPL-2+
     
     12
     
     13 Files: debian/*
     
     14 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org>
     
     15 License: GPL-2+
     
     16
     
     17 License: GPL-2+
     
     18  This program is free software; you can redistribute it and/or modify
     
     19  it under the terms of the GNU General Public License as published by
     
     20  the Free Software Foundation; either version 2 of the License, or
     
     21  (at your option) any later version. 
     
     22  .
     
     23  This program is distributed in the hope that it will be useful,
     
     24  but WITHOUT ANY WARRANTY; without even the implied warranty of
     
     25  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
     
     26  GNU General Public License for more details.
     
     27 .
     
     28  You should have received a copy of the GNU General Public License along
     
     29  with this program; if not, write to the Free Software Foundation, Inc.,
     
     30  51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
     
     31  .
     
     32  On Debian systems, the full text of the GNU General Public
     
     33  License version 2 can be found in the file
     
     34  `/usr/share/common-licenses/GPL-2'.

(Sono stati aggiunti i numeri di riga.)

Si prega di seguire l'HOWTO fornito da ftpmasters ed inviato a debian-devel-announce: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html.


4.3 Il file changelog

Questo è un file obbligatorio, che ha un formato speciale descritto nel Manuale delle policy di Debian, 4.4 'debian/changelog'. Questo formato è utilizzato da dpkg ed altri programmi per ottenere il numero di versione, revisione, distribuzione ed urgenza del pacchetto.

Tale file è anche utile allo scopo di aver documentato tutti i cambiamenti che sono stati fatti. Sarà inoltre d'aiuto agli utenti che scaricano il pacchetto per vedere se ci sono problemi di cui dovrebbero essere al corrente. Il file verrà salvato come /usr/share/doc/gentoo/changelog.Debian.gz nel pacchetto binario.

dh_make ne crea uno predefinito, ecco come appare:

     1  gentoo (0.9.12-1) unstable; urgency=low
     2
     3   * Initial release (Closes: #nnnn)  <nnnn is the bug number of your ITP>
     4
     5  -- Josip Rodin <joy-mg@debian.org>  Mon, 22 Mar 2010 00:37:31 +0100
     6

(Sono stati aggiunti i numeri di riga.)

La riga 1 indica il nome del pacchetto, la versione, la distribuzione e l'urgenza. Il nome deve corrispondere al nome del pacchetto sorgente, mentre la distribuzione dovrebbe essere unstable (o anche experimental) [17] , e l'urgenza non dovrebbe essere cambiata in qualcosa di più alto di low. :-)

Le righe 3-5 sono una voce del registro, in cui vengono documentati i cambiamenti fatti nella revisione del pacchetto (non dei cambiamenti del pacchetto originario - c'è un file apposta per questo scopo, creato dagli autori originali, che verrà installato successivamente /usr/share/doc/gentoo/changelog.gz). Supponiamo che il numero di servizio del ticket ITP fosse "12345". Nuove righe devono essere aggiunte appena prima della riga più in alto che comincia con "*" (asterisco). Ciò si può fare con dch(1), o manualmente con un editor testuale.

Alla fine si avrà qualcosa del genere:

     1  gentoo (0.9.12-1) unstable; urgency=low
     2
     3   * Initial Release. Closes: #12345
     4   * This is my first Debian package.
     5   * Adjusted the Makefile to fix $(DESTDIR) problems.
     6
     7  -- Josip Rodin <joy-mg@debian.org>  Mon, 22 Mar 2010 00:37:31 +0100
     8

(Sono stati aggiunti i numeri di riga.)

Si possono leggere ulteriori informazioni sull'aggiornamento del file changelog successivamente in Aggiornamento del pacchetto, Capitolo 9.


4.4 Il file rules

Ora si darà uno sguardo alle regole esatte che dpkg-buildpackage(1) userà per creare il pacchetto. In realtà questo file non è che un altro Makefile, ma diverso da quelli della sorgente originale. Differentemente dagli altri file sotto debian, questo qui è marcato come eseguibile.


4.4.1 Obiettivi del file rules

Ogni file rules, come qualsiasi altro Makefile, consiste di diversi obiettivi e regole che specificano come gestire il sorgente. Manuale delle policy di Debian, 4.9 'Script principale per la creazione: debian/rules' ne spiega i dettagli.

La spiegazione breve degli obiettivi è la seguente.

Le regole che si vogliono applicare vengono applicate come parametri da linea di comando (per esempio, "./debian/rules build" o "fakeroot make -f debian/rules binary"). Dopo il nome dell'obiettivo si può scrivere il nome della dipendenza, programma o file da cui dipende la regola. Dopo aver fatto questo ci può essere un qualsiasi numero di comandi, separati da TAB. Una nuova regola comincia con la dichiarazione dell'obiettivo nella prima colonna. Le righe vuote e le righe che cominciano con "#" (cancelletto) vengono trattate come commenti e rimosse.

È probabile che adesso ci sia un po' di confusione, ma sarà tutto più chiaro una volta esaminato il file rules che dh_make fornisce in modo predefinito. Inoltre si consiglia di leggere "info make" per maggiori informazioni.


4.4.2 Il file rules predefinito

Le nuove versioni di dh_make generano un file rules molto semplice ma potente utilizzando il comando dh:

      1 #!/usr/bin/make -f
      2 # -*- makefile -*-
      3 # Sample debian/rules that uses debhelper.
      4 # This file was originally written by Joey Hess and Craig Small.
      5 # As a special exception, when this file is copied by dh-make into a
      6 # dh-make output file, you may use that output file without restriction.
      7 # This special exception was added by Craig Small in version 0.37 of dh-make.
      8
      9 # Uncomment this to turn on verbose mode.
     10 #export DH_VERBOSE=1
     11
     12 %:
     13        dh $@

(Sono stati aggiunti i numeri di riga. Nel vero file rules, gli spazi vengono sostituiti da TAB.)

Probabilmente si sarà già familiari con le righe tipo la prima che ricordano gli script shell e Perl. In pratica indica al sistema operativo che il file andrà elaborato con /usr/bin/make.

La riga 10 può essere decommentata per impostare la variabile DH_VERBOSE ad 1. In tal caso, lo strumento debhelper fornirà più informazioni come risultato. Questo aiuta a capire cosa stia succedendo dietro questo semplice file rules ed ad analizzarne i problemi. Questo nuovo comando dh è una parte cruciale dello strumento debhelper e non nasconde nulla all'utente.

Tutto il lavoro è svolto nelle righe 12 e 13. Il simbolo della percentuale significa che ogni target esegue una chiamata ad un singolo programma, dh con il nome del terget stesso. [21] Il comando dh è uno script wrapper, che esegue una sequenza appropriata di programmi dh_* in base all'argomento passato. [22]

Le funzioni dei comandi dh_* sono quasi auto-esplicative dai loro nomi. [24] Ci sono una serie di appunti da fare in questa spiegazione semplificata che assume un ambiente di costruzione tipico basato su Makefile. [25]

Gli obiettivi che richiedono il comando fakeroot contengono dh_testroot. Se non si sta fingendo di essere root utilizzando questo comando, questo terminerà con un errore.

La cosa importante da sapere riguardo al file rules creato da dh_make, è che il suo contenuto contiene dei semplici consigli. Funzionerà per la maggior parte dei pacchetti ma per i più complicati non si esiti a personalizzarlo secondo le proprie esigenze. Le uniche cose che non vanno cambiate sono i nomi delle regole, perché tutti gli strumenti utilizzano questi nomi, così come è indicato dalle policy di Debian.

Anche se l'obiettivo "install" non è richiesto, è comunque supportato. "fakeroot dh install" si comporta come "fakeroot dh binary" ma si ferma dopo dh_fixperms.


4.4.3 Personalizzazione del file rules

Verrà qui spiegata la personalizzazione del file rules, creato con il nuovo comando dh.

Il comando "dh $@" può essere personalizzato come segue. [28]

Per i sorgenti che utilizzano Autotools, utilizzare il comando "dh --with autotools-dev --with autoreconf $@" per essere aggiornati con il sistema di compilazione GNU.

Molti comandi del tipo dh_*, invocati da dh, possono essere personalizzati modificando i rispettivi file di configurazione nella directory debian. Si veda Altri file nella directory debian, Capitolo 5 per la personalizzazione di tali caratteristiche.

Alcuni comandi del tipo dh_*, invocati da dh, possono richiedere la propria esecuzione con alcuni parametri o in aggiunta ad altri comandi da eseguire contestualmente o al posto dei comandi originali. In tali casi viene creato nel file rules l' obiettivo override_dh_foo aggiungendo una regola solo per il comando dh_foo che si intende modificare. Fondamentalmente tale regola dice "esegui me al posto di". [30]

Si noti che i comandi dh_auto_* tendono a fare più di quanto si sia qui illustrato in questa ultra-semplificata spiegazione per tenere in conto tutti casi limite. L'utilizzo di comandi semplificati nell'obiettivo override_dh_* è una cattiva idea in quanto potrebbe annullare molte delle caratteristiche utili di debhelper.

Se si vogliono registrare i dati di configurazione di sistema del pacchetto gentoo nella directory /etc/gentoo invece che nella solita directory /etc, si può sovrascrivere il parametro predefinito --sysconfig=/etc dato dal comando dh_auto_configure al comando ./configure nel modo seguente. [31]

     override_dh_auto_configure:
             dh_auto_configure -- --sysconfig=/etc/gentoo

I parametri immessi dopo -- vengono aggiunti dopo i parametri predefiniti dei programmi eseguiti pr sovrascriverli. Utilizzare il comando dh_auto_configure è preferibile rispetto al comando ./configure dal momento che sovrascriverà esclusivamente il parametro --sysconfig e manterrà gli altri parametri del comando ./configure.

Se il Makefile del sorgente per il pacchetto gentoo necessita che venga specificato l'obiettivo build per essere costruito [32], basterà creare l'obiettivo override_dh_auto_build pe abilitarlo.

     override_dh_auto_build:
             dh_auto_build -- build

Questo ci assicura che $(MAKE) verrà eseguito con tutti i parametri predefiniti del comando dh_auto_build ed il parametro di build.

Se il Makefile del sorgente di gentoo necessita che venga specificato il target packageclean per la pulizia del pacchetto Debian al posto dei target distclean o clean, basterà creare un target override_dh_auto_clean per abilitarlo.

     override_dh_auto_clean:
     
             $(MAKE) packageclean

Se il Makefile di un sorgente per il pacchetto gentoo contiene l'obiettivo test che non vuole essere eseguito nel processo di costruzione del pacchetto Debian, si può utilizzare l'obiettivo override_dh_auto_test per saltarlo.

     override_dh_auto_test:

Se il programma originale gentoo contiene un inusuale file di changelog chiamato FIXES, dh_installchangelogs non installerà questo file in modo predefinito. Il comando dh_installchangelogs richiede che venga fornito il parametro FIXES per installarlo.[33]

     override_dh_installchangelogs:
             dh_installchangelogs FIXES

Quando si usa il nuovo comando dh, l'utilizzo di target espliciti come quelli elencanti in Obiettivi del file rules, Sezione 4.4.1, tranne il target get-orig-source, possono rendere difficile capire i loro effettivi effetti. Si prega di limitare i target espliciti in favore dei target override_dh_* e, se possibile, quelli completamente indipendenti.


[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ successivo ]


Guida per il nuovo Maintainer

version 1.2.25, 2010-12-21 14:06:56 UTC

Josip Rodin joy-mg@debian.org
Traduzione: Calogero Lo Leggio kalos@nerdrug.org
Traduzione: Jacopo Reggiani jacopo.reggiani@gmail.com
Traduzione: Francesco P. Lovergine