pacchetti-e-repository.rst 23.9 KB
Newer Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
**********************
Pacchetti e Repository
**********************

La distribuzione FUSS comprende un repository di pacchetti aggiuntivi
rispetto alla base (Debian), disponibile all'indirizzo
https://archive.fuss.bz.it/ ed ospitato su ``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``.

17
18
19
Nei progetti sufficientemente recenti, tale directory è presente solo in
un branch dedicato, con un nome tipo ``fuss/<versione>``; per questi
casi vedere anche la sezione :ref:`pacchettizzazione-git` .
20

21
22
23
24
25
26
Setup
-----

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

27
    # apt install devscripts dput-ng dh-systemd dh-python
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

.. note:: 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``.

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.

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

    {
        "method": "sftp",
        "fqdn": "archive.fuss.bz.it",
        "incoming": "/iso/incoming/<versione>",
        "allow_dcut": false,
        "allowed-distribution": {},
        "codenames": null,
        "post_upload_command": "ssh -S none isolda.fuss.bz.it 'sudo /iso/bin/post-upload'",
        "hooks": [
            "allowed-distribution",
            "checksum",
            "suite-mismatch" 
        ]
    }

56
57
58
dove ``<versione>`` è ``jessie`` per FUSS server, ``stretch`` per FUSS
client, e ``buster`` e ``buster-proposed-updates`` per la prossima
versione di FUSS sia server che client.
59

Elena Grandi's avatar
Elena Grandi committed
60
61
62
63
64
65
66
67
68
69
70
71
.. tip:: in alcune versioni di dput-ng è presente un bug, `#952576
   <https://bugs.debian.org/cgi-bin/bugreport.cgi?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 isolda.fuss.bz.it '/iso/bin/post-upload 2>&1'",

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

72
Assicurarsi inoltre di poter accedere via ssh ad ``archive.fuss.bz.it`` senza
73
74
75
ulteriori opzioni; ad esempio potrebbe essere necessario aggiungere
quanto segue a ``~/.ssh/config``::

76
    Host archive.fuss.bz.it
77
78
79
80
81
82
83
84
85
86
87
        User root

.. note::  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.

Elena Grandi's avatar
Elena Grandi committed
88
   A marzo 2019 i fingerprint di isolda sono::
89
90
91
92
93

       256 SHA256:aLTgA+Trj5iYo0dl0i8Q82aigs3K/dPwDbazrvG95YY root@isolda (ECDSA)
       256 SHA256:7i6j0jXPWRrW6LXDGbR+HWr3AFJi6gGSmdW41uBRJV4 root@isolda (ED25519)
       2048 SHA256:OkP1maDf0pSIGCdq1mph8oI8CTADMrFXfe3aty608SA root@isolda (RSA)

Elena Grandi's avatar
Elena Grandi committed
94
95
96
97
       256 MD5:b1:a1:ec:cb:a5:39:c8:8d:39:f1:dd:ba:aa:be:38:11 root@isolda (ECDSA)
       256 MD5:21:41:8b:19:1b:25:b5:9c:f2:5c:e8:b9:8b:08:07:f8 root@isolda (ED25519)
       2048 MD5:bd:88:bd:5f:bc:52:03:0b:88:d9:0c:2b:86:59:dc:92 root@isolda (RSA)

98
Cowbuilder
99
^^^^^^^^^^
100

101
102
103
104
.. note::
   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.
105

106
107
108
109
110
111
   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
   jessie o stretch su un sistema buster)
112

Elena Grandi's avatar
Elena Grandi committed
113
114
Oltre a quanto indicato sopra, installare ``cowbuilder``, ``pbuilder`` e
``git-buildpackage``::
115

Elena Grandi's avatar
Elena Grandi committed
116
   # apt install pbuilder cowbuilder git-buildpackage
117
118
119
120

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

121
122
Quindi creare le chroot base per le distribuzioni attualmente (settembre
2020) in uso buster e stretch::
123

124
125
   # cowbuilder --create --distribution buster --debootstrap debootstrap \
     --basepath /var/cache/pbuilder/base-fuss-buster.cow
126
127
128
   # cowbuilder --create --distribution stretch --debootstrap debootstrap \
     --basepath /var/cache/pbuilder/base-fuss-stretch.cow

129
130
131
132
133
134
.. tip::
   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::

135
136
137
138
139
140
      --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
141

142
143
144
145
Aggiungere i repository di backports e fuss alle chroot base appena
create: fare login nella chroot::

   # cowbuilder --login --save-after-login \
146
     --basepath /var/cache/pbuilder/base-fuss-buster.cow
147
148
149
150
151

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

152
153
   # echo 'deb <mirror> buster-backports main' >> /etc/apt/sources.list
   # echo 'deb http://archive.fuss.bz.it/ buster main contrib' \
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
     >> /etc/apt/sources.list
   # apt install gnupg
   # apt-key add - # incollare i contenuti di
                   # https://archive.fuss.bz.it/apt.key seguiti da ctrl-d
   # apt remove gnupg
   # apt autoremove
   # apt update
   # exit

.. note::

   nella chroot minimale da stretch in poi non è presente gnupg, che è
   necessario per l'uso di apt-key add: lo installiamo per l'operazione
   e rimuoviamo subito dopo per essere certi che l'immagine sia sempre
   minimale e continuare ad accorgersi di eventuali dipendenze non
   esplicitate nei pacchetti che generiamo.

171
Ripetere la stessa cosa per l'altra chroot (``stretch``).
172
173
174
175

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

176
   # cowbuilder --update --basepath /var/cache/pbuilder/base-fuss-buster.cow/
177
178
   # cowbuilder --update --basepath /var/cache/pbuilder/base-fuss-stretch.cow/
   # cowbuilder --update --basepath /var/cache/pbuilder/base-fuss-jessie.cow/
179

180
181
Clone e/o aggiornamento del repository
--------------------------------------
182
183
184

Clonare il repository del progetto desiderato::

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


188
Nei vecchi progetti il branch da buildare per l'upload è ``master``, in
189
190
191
quelli recenti ``fuss/*`` (``fuss/master`` o altro a seconda del
target), in entrambi i casi da aggiornare nel caso in cui si abbia già
un clone locale del repository::
192

193
   $ git checkout [fuss/]master
194
   $ git pull
195

196
197
198
199
Nel caso si stia facendo una release per un pacchetto recente
(pacchettizzazione in ``fuss/*``) ricordarsi di aggiornare il branch con
le modifiche che si vogliono integrare nella release.

200
.. hint::
Elena Grandi's avatar
Elena Grandi committed
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
   Ad esempio, per fare una release della versione di sviluppo attivo di
   un pacchetto recente, si inizia assicurandosi di avere la versione
   corrente del branch di sviluppo, ``master``::

      $ git checkout master
      $ git pull

   si controlla eventualmente che il numero di versione in ``setup.py``
   sia corretto, ed eventualmente lo si aggiorna e committa::

      $ $EDITOR setup.py
      $ git add -p setup.py
      [...]
      $ git commit -m 'Bump version to <version>'
      $ git push

   si passa al branch con la pacchettizzazione, assicurandosi che anche
   questo sia aggiornato::

      $ git checkout fuss/master
      $ git pull

   e si fa il merge del branch di sviluppo::

      $ git merge master
      $ git push

   a questo punto si procede come descritto al prossimo punto
   aggiornando il changelog del pacchetto, eccetera.

231
232
233
234
Versionamento
-------------

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

Elena Grandi's avatar
Elena Grandi committed
237
238
239
Il numero di versione da dare dipende dal tipo di pacchetto, come
descritto nella sezione :ref:`versionamento` e nelle guide di sviluppo
degli specifici pacchetti, ma nella maggior parte dei casi sarà da
240
incrementare il patch level (es. da 10.0.5-1 a 10.0.6-1).
241
242
243
244
245

.. note:: 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.
246

247
248
249
250
   Notare che l'aggiornamento del numero di versione in ``setup.py`` va
   effettuato nel branch di sviluppo, e non in quello di
   pacchettizzazione.

251
252
253
Il programma ``dch``,  permette di automatizzare l'editing del file
``debian/changelog`` che contiene la versione del pacchetto.

254
255
256
* 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.
257

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

261
262
263
264
  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.
265

266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
  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``.
285

286
287
288
289
290
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
291
corretto (``master`` o ``fuss/*`` a seconda dell'età del progetto),
292
293
294
295
ad esempio con il comando::

   $ git status

296
297
298
299
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"::
300
301
302
303
304
305
306
307
308
309
310

   $ 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

311
312
313
314
315
316
317
318
319
Build
-----

Alcuni pacchetti, come 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::

320
   $ debian/rules debsrc
321

322
323
A questo punto si può usare ``pdebuild`` per eseguire la build del
pacchetto all'interno di una chroot opportuna gestita da cowbuilder
324
325
(sostituendo ``buster`` con ``stretch`` o ``jessie`` nei casi
opportuni)::
326

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

329
330
``pdebuild`` provvederà autonomamente ad installare le dipendenze
necessarie all'interno della chroot e ad effettuare la build.
331

332
333
334
335
336
337
338
Generalmente, l'infrastruttura di build [#infrastruttura]_ è 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::
Elena Grandi's avatar
Elena Grandi committed
339

340
   $ DIST=buster pdebuild --buildresult ../build/ --use-pdebuild-internal --pbuilder cowbuilder --debbuildopts "-sa" -- --basepath /var/cache/pbuilder/base-fuss-buster.cow/
Elena Grandi's avatar
Elena Grandi committed
341

Elena Grandi's avatar
Elena Grandi committed
342
343
344
345
346
347
348
.. note::
   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``.

349
350
351
352
353
354
355
.. [#infrastruttura] 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.
Elena Grandi's avatar
Elena Grandi committed
356

Elena Grandi's avatar
Elena Grandi committed
357
358
359
360
361
362
363
364
365
366
Build con git-buildpackage
^^^^^^^^^^^^^^^^^^^^^^^^^^

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.

Elena Grandi's avatar
Elena Grandi committed
367
368
369
370
371
372
373
374
375
376
377
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::
Elena Grandi's avatar
Elena Grandi committed
378
379
380
381

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

382
383
384
Per forzare l'inclusione della tarball sorgente dei backports, come
spiegato sopra, in questo caso è sufficiente aggiungere ``-sa``.

385
386
387
Test
----

388
389
Tramite ``apt install ./<nomefile>.deb`` si puo' installare e testare il
pacchetto.  Notare l'uso di ``./`` per specificare un file locale.
390
391
392
393

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

394
395
lintian
^^^^^^^
396

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

401
   lintian --pedantic -Iiv <pacchetto>.changes
402

403
404
405
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.
406

407
In particolare si possono ignorare i seguenti tag.
408

409
410
411
412
* ``changelog-should-mention-nmu``
* ``source-nmu-has-incorrect-version-number``

ed altri che verranno successivamente aggiunti a questo elenco.
413
414
415
416
417
418
419

Upload
------

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

420
    $ dput fuss-<versione> nomepacchetto_versione_arch.changes
421
422
423
424
425
426
427
428
429
430

Nel caso si voglia procedere manualmente invece si possono copiare i
file generati su ``isolda`` nella directory ``/iso/incoming/<versione>``
ed aggiornare il repository con il comando::

    # /iso/bin/post-upload

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

431
432
433
434
435
436
Tagging
-------

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

437
   $ git tag -s -m 'Fuss release <versione>' fuss/<versione>
438
439
440
441

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

442
   $ git tag -a -m 'Fuss release <versione>' fuss/<versione>
443
444
445

Ricordarsi di effettuare il push dei tag verso il server::

446
   $ git push --tags
447

448
.. _chroot:
449

450
451
Build dei pacchetti in chroot
=============================
452

453
454
455
Nel caso ci siano problemi con l'uso di cowbuilder, è anche possibile
usare una semplice chroot all'interno della quale installare gli
strumenti di build e clonare il pacchetto.
456
457
458
459

Setup
-----

460
Per creare una chroot ed installare gli strumenti di base::
461

462
463
464
465
    # mkdir <versione>_build
    # debootstrap <versione> <versione>_build (<mirror>)
    # chroot <versione>_build
    # apt install debhelper devscripts dpkg-dev
466

467
468
469
dove ``<versione>`` è al momento (settembre 2020) ``buster`` per FUSS
server e client correnti e ``stretch`` per il supporto legacy del solo
FUSS client.
470
471
472
473

Build
-----

474
475
476
477
Una volta clonato il repository (dentro la chroot), incrementato il
numero di versione come sopra ed eventualmente generato il tar sorgente,
per eseguire il build del pacchetto eseguire, nella directory principale
del repository::
478

479
    # dpkg-buildpackage -us -uc
480

481
482
483
Se la procedura va a buon fine, nella directory superiore si troveranno
i pacchetti ``.deb`` generati, e anche i file ``.changes``, ``.dsc`` e
``.tar.gz`` con il sorgente del pacchetto.
484

485
La procedura potrebbe fallire con un errore contenente::
486

487
488
489
490
491
492
    Unmet build dependencies: <pacchetto1> <pacchetto2>

in tal caso installare semplicemente i pacchetti e riprovare.
Tali dipendenze sono elencate nel campo ``Build-Depends`` del file
``debian/control``, nel caso ci si voglia assicurare di averle già
installate prima di buildare.
493
494
495
496

A questo punto si può procedere con test, commit+push ed upload come nel
caso generale.

Elena Grandi's avatar
Elena Grandi committed
497
498
.. _versionamento:

Elena Grandi's avatar
Elena Grandi committed
499
500
501
502
503
504
505
506
507
508
509
510
511
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).
512
513
Un pacchetto per FUSS 9 avrà quindi versione tipo 9.X.Y, uno per FUSS 10
10.X.Y eccetera.
Elena Grandi's avatar
Elena Grandi committed
514
515

I pacchetti possono essere nativi o meno: nel primo caso il numero di
516
517
versione è del tipo 10.X.Y sia per il pacchetto che in ``setup.py``,
mentre nel secondo si aggiunge un numero di revisione, es. 10.X.Y-Z;
Elena Grandi's avatar
Elena Grandi committed
518
519
520
521
522
523
524
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
525
sorgente (``<nome>_<10.X.Z>.orig.tar.gz``), ad esempio tramite
Elena Grandi's avatar
Elena Grandi committed
526
527
528
529
530
531
532
533
534
535
536
537
538
``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.

.. _backports: https://backports.debian.org/

Se si fa una rebuild di un pacchetto che ad esempio ha versione 1.2.3-4
539
la nostra versione sarà 1.2.3-4~fuss10+1 (+2 per una rebuild successiva
Elena Grandi's avatar
Elena Grandi committed
540
541
con modifiche alla sola pacchettizzazione, eccetera).

542
543
Configurazione del repository
=============================
Elena Grandi's avatar
Elena Grandi committed
544
545
546
547
548
549

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

    Origin: FUSS
    Label: FUSS
550
551
552
    Suite: buster
    Codename: buster
    Version: 10.0
Elena Grandi's avatar
Elena Grandi committed
553
554
    Architectures: i386 amd64 source
    Components: main contrib
555
    Description: FUSS 10.0
Elena Grandi's avatar
Elena Grandi committed
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
    SignWith: C00D47EF47AA6DE72DFE1033229CF7A871C7C823

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

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 - https://archive.fuss.bz.it/apt.key | apt-key add -

Aggiunta di nuova distribuzione e/o nuovo repository
----------------------------------------------------

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

* Creare una cartella per lo spool di incoming dei pacchetti in
  ``/iso/incoming/<nuova distribuzione>``
* Aggiungere la descrizione e il path relativo al punto precedente nel
  file ``/iso/repo/conf/incoming``
* Aggiungere allo script ``/iso/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.
586

587
588
.. _pacchettizzazione-git:

Elena Grandi's avatar
typo    
Elena Grandi committed
589
590
Pacchettizzazione gestita con git
=================================
591

592
593
594
Come descritto nelle istruzioni, nei progetti più recenti si è adottata
una delle convenzioni in uso in Debian per la pacchettizzazione basata
su git.
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620

* I branch di sviluppo del progetto, incluso ``master`` non contengono
  la directory ``debian``, come da raccomandazione della `UpstreamGuide
  <https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source>`_ 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-buster

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.

621
622
623
624
625
626
627
628
629
630
631
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.


632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
Pacchetti particolari
=====================

coova-chilli
------------

Il pacchetto coova-chilli presente su archive.fuss.bz.it è generato da
un nostro repository https://work.fuss.bz.it/git/coova-chilli copia del
repository upstream https://github.com/coova/coova-chilli.git alla quale
abbiamo aggiunto alcune modifiche di pacchettizzazione.

In particolare, per la release 1.4 è presente un branch ``1.4-patched``
con dei bugfix alla pacchettizzazione che sono stati nel frattempo
`accettati upstream <https://github.com/coova/coova-chilli/pull/333>`_
per le versioni successive.

Per effettuare nuove build della versione 1.4 è quindi necessario usare
il branch ``1.4-patched``, mergiandovi eventuali modifiche upstream
desiderate; usando ``git-buildpackage`` si dovrà usare::

   $ gbp buildpackage --git-debian-branch=1.4-patched [--git-pbuilder]

Per versioni successive si possono invece usare i tag pubblicati da
upstream.

Altri branch presenti sul nostro repository contengono la
pacchettizzazione per versioni precedenti di FUSS, di utilità solo
storica.