Pacchetti e Repository

La distribuzione FUSS comprende un repository di pacchetti aggiuntivi rispetto alla base (Debian), disponibile all’indirizzo https://archive.fuss.bz.it/ , gestito, generato e firmato su una macchina privata e servito via http(s) da isolda.fuss.bz.it nella directory /iso/repo.

Build dei pacchetti

Nei repository del software sviluppato per FUSS è presente la directory debian contenente i file necessari per la generazione dei pacchetti .deb.

Setup

Per effettuare build locali dei pacchetti è necessario installare alcuni strumenti di sviluppo:

# apt install devscripts dput-ng dh-python

Nota

Assicurarsi di aver installato anche i Recommends dei pacchetti (questo è il comportamento di default di apt, a meno che non lo si sia disabilitato manualmente), in particolare nel caso di dput-ng.

Nota

su bookworm è necessario installare dput-ng da backports:

# apt install -t bookworm-backports dput-ng

Inoltre è necessario impostare le variabili di ambiente DEBEMAIL e DEBFULLNAME, contenenti rispettivamente il nome completo e l’email dello sviluppatore, che verranno usate per aggiornare alcuni metadati.

Se si lavora solo su pacchetti per FUSS, dove non vengono usati i Non Maintainer Upload (NMU), può essere utile impostare in ~/.devscripts:

DEBCHANGE_AUTO_NMU=no

in questo modo usando dch per le modifiche dei changelog non ci sarà bisogno di fare attenzione che, a seconda di chi ha effettuato l’upload precedente, non venga usato un numero di versione con l’incremento sbagliato.

Per usare dput-ng per effettuare gli upload serve configurarlo creando il file ~/.dput.d/profiles/fuss-<versione>.json contenente:

{
    "method": "rsync",
    "fqdn": "packages.private.fuss.bz.it",
    "incoming": "/home/reprepro/repo/incoming/<versione>",
    "allow_dcut": false,
    "allowed-distribution": {},
    "codenames": null,
    "post_upload_command": "ssh -S none packages.private.fuss.bz.it 'sudo -u reprepro /home/reprepro/bin/post-upload'",
    "hooks": [
        "allowed-distribution",
        "checksum",
        "suite-mismatch"
    ]
}

dove <versione> è bookworm e bookworm-proposed-updates per la versione corrente di FUSS server e client, e trixie e trixie-proposed-updates per la versione in fase di sviluppo.

Suggerimento

in alcune versioni di dput-ng è presente un bug, #952576 per cui eventuali errori di post-upload non vengono riportati, rendendo silenzioso il fallimento. Se si incappa in quella situazione, un possibile workaround è sostituire la configurazione di post_upload_command con la seguente:

"post_upload_command": "ssh -S none packages.private.fuss.bz.it 'sudo -u reprepro /home/reprepro/bin/post-upload 2>&1'",

in modo che eventuali errori vengano rediretti su stdout e vengano visualizzati.

Assicurarsi inoltre di poter accedere via ssh ad packages.private.fuss.bz.it senza ulteriori opzioni, aggiungendo eventuali opzioni necessarie a ~/.ssh/config.

Nota

dput-ng usa paramiko per effettuare le connessioni ssh; questo implica che le opzioni impostate direttamente in ~/.ssh/config vengono lette correttamente, ma non c’è supporto per l’uso di Include per suddividere la configurazione su più file.

Inoltre non verrà salvato il fingerprint dei server, ma verrà chiesto ogni volta di verificarlo.

A giugno 2025 i fingerprint di packages sono:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC5t/khy7+U4twrgZxBJr5hOEfwrII/Y6/A3Ta25PDrDkA2bCD75iqrufdl7IKDAukTKR5XgbgTMlxq9xm90NHYcM4MkS8e+f8J0seenAVTaDC7D+R9GbudHMJM48ZgpVOAHFHYdiaDGQTrBberqkbArkJwgZV2m6HCOrwGnKsVDXaCETrTLtGBTTuvyySpiy6vDAFiLdhXOz3S7xkqlPUXe9LhTbzC5wtCUgfPqzRLVq30jzuvu6UjKfoNawBDB6VxoH618mrYxBwNgVNcG7g4ukggHStN2KeF7/URky7UH+IfxqHnvwSQpAm2OUq//2hBnLw6JdmkaG3shZ9i33edkzXdA+KQa6FYEK3DrLsWFt5oA0MaI1BUf5eUypUot0JSenhoiBfB1ftphqfF13gwR2QdZNF3VWeBfa57Z2IS3Z3kQ+vjZaeNP2SCbox1TCYUIzWRhls96tuqssqOi3ocjWlBVhM3nEYM7xZHKSqR8Cnh6YqLE6cB4HX4wY/V+HM=

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBM3jDIQKNPSEAFYSa8ah0VuoywgyJfSoXpT//D9AMqXSoW2Ffk48NyFcaVe40dfgDdpsxKDYFTkNzrSRadq8Hsc=

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHE0SSNEe60MOvn50lTQjZO7Wg7VyE7QvQUdPWFejZLs

Cowbuilder

Nota

cowbuilder e pbuilder sono degli strumenti per gestire delle chroot all’interno delle quali effettuare build di pacchetti in un ambiente pulito e abbastanza isolato dal sistema base.

Buildare pacchetti all’interno di un sistema isolato è utile per evitare influenze da parte del proprio sistema (con librerie ed altre dipendenze già installate, magari in versioni non standard), ma è anche comodo nel caso si vogliano generare pacchetti per distribuzioni diverse da quelle in uso (ad esempio buildare per bookworm su un sistema trixie)

Oltre a quanto indicato sopra, installare cowbuilder, pbuilder e git-buildpackage:

# apt install pbuilder cowbuilder git-buildpackage

ed assicurarsi che l’utente che si vuole usare per lanciare le build faccia parte del gruppo sudo.

Quindi creare le chroot base per le distribuzioni attualmente (marzo 2026) in uso bookworm e trixie:

# cowbuilder --create --distribution bookworm --debootstrap debootstrap \
  --basepath /var/cache/pbuilder/base-fuss-bookworm.cow
# cowbuilder --create --distribution trixie --debootstrap debootstrap \
  --basepath /var/cache/pbuilder/base-fuss-trixie.cow

Suggerimento

cowbuilder può essere usato anche sotto distribuzioni derivate da debian, come ubuntu; in questo caso è necessario però specificare esplicitamente l’uso di un mirror debian aggiungendo ai comandi sopra le opzioni:

--mirror http://<un mirror debian valido>/debian --components main

inoltre per il funzionamento è necessario disporre delle chiavi di firma GPG di Debian, che in genere si installano con:

apt-get install -y debian-archive-keyring

Aggiungere i repository di backports e fuss alle chroot base appena create: scaricare la versione più recente del pacchetto fuss-archive-keyring e salvarla nella chroot, ad esempio a giugno 2025:

# wget -O \
  /var/cache/pbuilder/base-fuss-bookworm.cow/root/fuss-archive-keyring_0.20250620_all.deb \
  https://archive.fuss.bz.it/pool/main/f/fuss-archive-keyring/fuss-archive-keyring_0.20250620_all.deb

quindi fare login nella chroot:

# cowbuilder --login --save-after-login \
  --basepath /var/cache/pbuilder/base-fuss-bookworm.cow

installare il pacchetto appena scaricato (e cancellarlo per pulizia):

# cd /root
# apt install ./fuss-archive-keyring_*.deb
# rm ./fuss-archive-keyring_*.deb

ed effettuare le modifiche a /etc/apt/sources.list (sostituendo <mirror> con un mirror debian opportuno, ad esempio quello già presente in /etc/apt/sources.list:

# cat << EOF > /etc/apt/sources.list.d/fuss.sources
  Types: deb
  URIs: http://archive.fuss.bz.it/
  Suites: bookworm
  Components: main contrib
  Signed-By: /usr/share/keyrings/fuss-keyring.gpg
  EOF
# cat << EOF >> /etc/apt/sources.list.d/debian.sources
  Types: deb
  URIs: <mirror>
  Suites: bookworm-backports
  Components: main contrib
  Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
  EOF
# apt update
# exit

Ripetere la stessa cosa per le altre eventuali chroot, cambiando opportunamente il valore di Suites.

Nel caso in cui le chroot siano state create da un po” di tempo è opportuno aggiornarle, coi seguenti comandi:

# cowbuilder --update --basepath /var/cache/pbuilder/base-fuss-bookworm.cow/
# cowbuilder --update --basepath /var/cache/pbuilder/base-fuss-trixie.cow/

Clone e/o aggiornamento del repository

Clonare il repository del progetto desiderato:

$ git clone https://work.fuss.bz.it/git/<progetto>

Il branch da buildare per la versione di sviluppo è master, da aggiornare nel caso in cui si abbia già un clone locale del repository:

$ git checkout master
$ git pull

Versionamento

Per poter pubblicare il pacchetto, è necessario incrementare il numero di versione nel file debian/changelog.

Il numero di versione da dare dipende dal tipo di pacchetto, come descritto nella sezione Policy di versionamento e nelle guide di sviluppo degli specifici pacchetti, ma nella maggior parte dei casi sarà da incrementare il patch level (es. da 13.0.5-1 a 13.0.6-1).

Nota

Nei pacchetti contenenti programmi in python è generalmente necessario mantenere aggiornato il numero di versione anche in setup.py; come per debsrc sopra questo dovrebbe essere citato nel README dei pacchetti.

Il programma dch, permette di automatizzare l’editing del file debian/changelog che contiene la versione del pacchetto.

• Quando si iniziano a fare modifiche usare il comando dch -v <nuova_versione> per creare una nuova stanza ed aprire il changelog nell’editor di default.

  Verrà impostato il numero di versione richiesto e la release speciale UNRELEASED che indica che le modifiche sono ancora in lavorazione.

  Si può anche usare dch senza opzioni: in questo modo se l’ultima stanza risulta UNRELEASED il file verrà aperto così com’è, mentre se l’ultima stanza riporta una release come unstable ne viene creata una nuova incrementando il numero di versione.

  Attenzione che in quest’ultimo caso dch potrebbe non essere in grado di indovinare la versione corretta: verificare e nel caso correggere. Inoltre, nel caso in cui non si sia elencati tra i Maintainer e Uploaders in debian/control verrà aggiunta una riga Non Maintainer Upload che per noi non è rilevante e va tolta.

  Nel caso in cui più persone facciano modifiche, dch provvederà a suddividerle in sezioni intestate con il nome della persona che ha effettuato la modifica.

• Descrivere le modifiche effettuate, possibilmente indicando i ticket di riferimento da cui nascono le richieste di modifica.

• Man mano che si fanno modifiche, descriverle se necessario nel changelog, usando dch senza opzioni, come descritto sopra.

• Quando si è pronti a pubblicare il pacchetto, modificare UNRELEASED con unstable nella prima riga; questo si può fare anche con il comando dch -r.

Verifica dello stato del repository e push

Prima di effettuare la build, accertarsi di aver committato tutte le modifiche effettuate, di non avere file spuri e di essere sul branch corretto, ad esempio con il comando:

$ git status

Committare quindi eventuali modifiche rimanenti, facendo attenzione a mantenere distinte le modifiche di sviluppo da quelle di pacchettizzazione, indicando se possibile nel commit log il numero di ticket associato alla modifica, con la dicitura «refs #NUMERO»:

$ git add -p <file modificati>
$ git add <file aggiunti>
$ git commit -m "<modifiche effettuate>. refs #NumeroTicket"

Inoltre o subito prima o subito dopo la build, ma prima dell’upload, è importante pushare tali commit, in modo da essere sicuri che nel frattempo non avvengano conflitti con commit altrui:

$ git push

Build

Alcuni pacchetti, come ad esempio octofussd necessitano della preventiva creazione del tar dei sorgenti originali, come specificato nel README dei rispettivi repository; in tal caso prima di eseguire il comando precedente è necessario eseguire, nella directory principale del repository:

$ debian/rules debsrc

A questo punto si può usare pdebuild per eseguire la build del pacchetto all’interno di una chroot opportuna gestita da cowbuilder (sostituendo trixie con bookworm nei casi opportuni):

$ DIST=trixie pdebuild --use-pdebuild-internal --pbuilder cowbuilder -- --basepath /var/cache/pbuilder/base-fuss-trixie.cow/

pdebuild provvederà autonomamente ad installare le dipendenze necessarie all’interno della chroot e ad effettuare la build.

Generalmente, l’infrastruttura di build [1] è in grado di capire dal numero di versione ed altri indizi se sia necessario o meno includere la tarball .orig tra ciò che va uploadato. Nel caso in cui però si stia effettuando un backport questo non è automatico: per il primo backport di una certa versione upstream è necessario prevedere l’inclusione della tarball sorgente con l’opzione --debbuildopts "-sa", ovvero:

$ DIST=trixie pdebuild --buildresult ../build/ --use-pdebuild-internal --pbuilder cowbuilder --debbuildopts "-sa" -- --basepath /var/cache/pbuilder/base-fuss-trixie.cow/

Nota

Alla fine della build si riceverà un warning cannot create regular file /var/cache/pbuilder/result/<nomepacchetto>_<versione>.dsc; questo è irrilevante e i file necessari che sono stati generati si trovano nella directory superiore a quella da cui è stato lanciato pdebuild.

[1]

In particolare, l’inclusione o meno della tarball sorgente è decisa ed effettuata da dpkg-genchanges, richiamato da dpkg-buildpackage al quale pdebuild passa le opzioni specificate con il parametro --debbuildopts.

Generalmente questo avviene in automatico, senza bisogno di preoccuparsi di chi faccia cosa.

Build con git-buildpackage

Nota

questo paragrafo non è applicabile ai progetti attualmente in sviluppo, bisogna verificare se sia possibile usare gbp senza i branch separati.

In alternativa all’uso diretto di pdebuild, ma solo per i progetti il cui repository lo supporti tramite l’uso di un branch separato per la pacchettizzazione, è possibile usare git-buildpackage (o gbp): oltre ad effettuare la build in una chroot minimale questo si assicura anche che non ci siano differenze tra quanto committato (localmente) e quanto viene usato per la build.

Per effettuare la build in questo caso è necessario spostarsi sul branch di pacchettizzazione, ad esempio:

$ git checkout fuss/master

eventualmente riportare in tale branch le modifiche effettuate su master:

$ git merge master

e quindi si può buildare, nel caso generale con:

gbp buildpackage --git-pbuilder --git-debian-branch=fuss/master \
   --git-dist=fuss-trixie --git-no-pristine-tar

Per forzare l’inclusione della tarball sorgente dei backports, come spiegato sopra, in questo caso è sufficiente aggiungere -sa.

Test

Tramite apt install ./<nomefile>.deb si puo” installare e testare il pacchetto. Notare l’uso di ./ per specificare un file locale.

Un altro comando utile è dpkg -c <nomefile>.deb per verificare i file presenti nel pacchetto.

lintian

Uno strumento di diagnostica molto dettagliato è lintian, che analizza i pacchetti generati alla ricerca di problemi di vario tipo e si lancia con:

lintian --pedantic -Iiv <pacchetto>.changes

Un limite di questo strumento è che è basato sugli standard di Debian e in alcuni casi gli errori potrebbero essere falsi positivi per gli standard fuss.

In particolare si possono ignorare i seguenti tag.

• changelog-should-mention-nmu

• source-nmu-has-incorrect-version-number

ed altri che verranno successivamente aggiunti a questo elenco.

Upload

Per uploadare il pacchetto buildato con dput-ng è sufficiente usare il comando:

$ dput fuss-<versione> nomepacchetto_versione_arch.changes

Nel caso si voglia procedere manualmente invece si possono copiare i file generati su packages nella directory /home/reprepro/repo/incoming/<versione> ed aggiornare il repository con il comando:

# sudo -u reprepro /home/reprepro/bin/post-upload

Verificare poi che in /home/reprepro/repo/incoming/<versione> non siano rimasti file spuri, e nel caso cancellarli a mano.

Tagging

Nel momento in cui tutto è pronto per un upload, taggare il commit corrispondente a quanto verrà uploadato con il comando:

$ git tag -s -m 'Fuss release <versione>' fuss/<versione>

in questo modo il tag verrà firmato con la propria chiave gpg di default; per non firmare il tag:

$ git tag -a -m 'Fuss release <versione>' fuss/<versione>

Ricordarsi di effettuare il push dei tag verso il server:

$ git push --tags

Policy di versionamento

Software sviluppato per FUSS

Per i pacchetti sviluppati specificatamente per FUSS possono esserci policy specifiche indicate nella relativa guida sviluppatori e/o nei README dei progetti.

In generale, lo schema usato prevede che la major version corrisponda alla versione di fuss per cui è rilasciato il pacchetto (che a sua volta corrisponde alla versione di debian su cui è basta). Un pacchetto per FUSS 12 avrà quindi versione tipo 12.X.Y, uno per FUSS 13 13.X.Y eccetera.

I pacchetti possono essere nativi o meno: nel primo caso il numero di versione è del tipo 13.X.Y sia per il pacchetto che in setup.py, mentre nel secondo si aggiunge un numero di revisione, es. 13.X.Y-Z; quest’ultimo va incrementato quando la nuova versione presenta modifiche nella pacchettizzazione (ovvero nella directory debian), ma non nel codice.

I pacchetti nativi devono anche avere 3.0 (native) nel file debian/source/format, mentre i pacchetti non-nativi devono avere 3.0 (quilt) e per buildarli è necessario generare una tarball sorgente (<nome>_<13.X.Z>.orig.tar.gz), ad esempio tramite debsrc.

Rebuild di pacchetti di debian

Per i pacchetti presi da debian e ribuildati da noi seguiamo una convenzione simile a quella usata dai backports aggiungendo ~fussN-X al numero di versione, dove N è la versione di FUSS per la quale stiamo preparando il pacchetto e X la revisione del backport.

Se si fa una rebuild di un pacchetto che ad esempio ha versione 1.2.3-4 la nostra versione sarà 1.2.3-4~fuss13+1 (+2 per una rebuild successiva con modifiche alla sola pacchettizzazione, eccetera).

Configurazione del repository

Il file /home/reprepro/repo/conf/distributions definisce le distribuzioni utilizzate nel repository, con snippet di configurazione come:

Origin: FUSS
Label: FUSS
Suite: bookworm
Codename: bookworm
Version: 12.0
Architectures: i386 amd64 source
Components: main contrib
Description: FUSS 12.0
SignWith: C00D47EF47AA6DE72DFE1033229CF7A871C7C823

inoltre nello stesso file sono definite le versioni precedenti e future della distribuzione. Al momento attuale la configurazione riguarda fino alla versione 13 di Debian (codename trixie).

Le varie distribuzioni sono raggiungibili da apt usando, in /etc/apt/sources.list:

deb http://archive.fuss.bz.it CODENAME_DISTRIBUZIONE main contrib

e la chiave con la quale viene firmato il repository si può installare su una macchina debian o derivate eseguendo, da root:

# wget -qO /usr/share/keyrings/fuss-keyring.gpg https://archive.fuss.bz.it/apt.key

Aggiunta di nuova distribuzione e/o nuovo repository

Oltre al file /home/reprepro/repo/conf/distributions per indicare la nuova distribuzione e/o nuovo repository, è necessario:

• Creare (gpg --gen-key) una nuova chiave gpg per la firma dei pacchetti di quella documentazione, con scadenza nello stesso giorno della chiave della versione corrispondente di Debian, ed indicarla in /home/reprepro/repo/conf/distributions.

• Aggiornare il pacchetto fuss-archive-keyring.

• Creare una cartella per lo spool di incoming dei pacchetti in /home/reprepro/repo/incoming/<nuova distribuzione>

• Aggiungere la descrizione e il path relativo al punto precedente nel file /home/reprepro/repo/conf/incoming

• Aggiungere allo script /home/reprepro/bin/post-upload l’esecuzione del processing del nuovo path di incoming. In questo script vanno tolte quelle non più usate quando è certo che non ci saranno più nuovi pacchetti per una specifica distribuzione.

Copia di pacchetti tra distribuzioni diverse

reprepro permette di copiare dei pacchetti già caricati per una distribuzione in una distribuzione diversa; questo è utile ad esempio per portare un pacchetto da <distro>-proposed-updates a <distro> una volta che si è appurato il corretto funzionamento.

Il comando è:

root@packages:/home/reprepro/repo# sudo -u reprepro reprepro copy bookworm bookworm-proposed-updates <nome_pacchetto>

dove si deve fare attenzione che la prima distribuzione specificata è quella di destinazione, seguida dalla distribuzione di origine.

In seguito ci si deve ricordare di sincronizzare il repository pubblicato su isolda con il comando:

root@packages:/home/reprepro/repo# sudo -u reprepro /home/reprepro/bin/sync_repo.sh

Verifica delle versioni presenti sul repository

Per sapere che versioni di un pacchetto sono presenti in che distribuzione basta usare il comando:

reprepro ls <nomepacchetto>

Pacchettizzazione per progetti usabili extra-fuss

Nota

al momento non ci sono progetti a cui si applichi questo paragrafo.

Nel caso in cui si sviluppino progetti usabili al di fuori di FUSS, la loro pacchettizzazione viene gestita in modo diverso

• I branch di sviluppo del progetto, incluso master non contengono la directory debian, come da raccomandazione della UpstreamGuide di Debian.

• I branch il cui nome inizia per fuss/ contengono la directory debian; generalmente il branch usato per gli upload della versione corrente sarà fuss/master.

• Ad ogni rilascio, il branch master viene mergiato in fuss/master (ma mai il contrario) e il pacchetto può essere generato con i metodi descritti sopra.

Nel caso si voglia effettuare la build con gbp (pacchetto git-buildpackage il comando da usare sarà:

gbp buildpackage \
--git-pbuilder \
--git-no-pristine-tar \
--git-debian-branch=fuss/<versione> \
--git-dist=fuss-bookworm

aggiungendo --git-export=WC per fare build di prova dello stato attuale della working directory (anziché dello stato all’ultimo commit) oppure --git-ignore-new per fare una build corrispondente all’ultimo commit, ignorando le modifiche eventualmente presenti.

Configurazioni standard e nuovi pacchetti

Maintainer

Il campo Maintainer di debian/control deve avere come valore FUSS team <packages@fuss.bz.it>, in modo da indicare che il pacchetto è manutenuto da un team.

Pacchetti particolari

fuss-archive-keyring

Il pacchetto fuss-archive-keyring contiene un keyring (nel formato OpenPGP) contenente tutte le chiavi pubbliche usate per firmare le varie versioni del repository.

Quando si crea una nuova chiave per firmare una nuova versione del repository, su packages.private.fuss.bz.it, si deve poi, con l’utente reprepro usare il comando gpg --export > fuss-keyring.pgp per avere la versione aggiornata del file con cui aggiornare il pacchetto.

Il pacchetto generato va poi caricato per tutte le versioni di fuss attualmente supportate; per questo motivo il numero di versione usato non dipende dalla versione fuss, ma è la data di rilascio nel formato 0.YYYYMMDD.

Vedere anche

• https://wikitech.wikimedia.org/wiki/Reprepro#HOWTO