Inviare un PR
Da Wiki di NetBSD Italia.
m (→Servono info aggiuntive ?: metto a posto le accento e correggo altri errori di battitura e slang (OMG! :-))) |
|||
| Riga 335: | Riga 335: | ||
Per leggere tutte le email riguardo al nostro PR: {{PR|39142}} | Per leggere tutte le email riguardo al nostro PR: {{PR|39142}} | ||
| - | == | + | == Aggiungere maggiori informazioni ad un PR == |
| - | Se credete di avere ulteriori informazioni sul | + | Se credete di avere ulteriori informazioni sul PR di cui siete venuti a |
| + | conoscenza solo dopo aver già fatto il report, o semplicemente che vi siete | ||
| + | dimenticati di accludere potete rispondere al messaggio di conferma che vi è | ||
| + | arrivato da gnats-bugs@netbsd.org. Provvederà gnats-bugs@netbsd.org stesso | ||
| + | (leggendo il subject) ad aggiungere le informazioni nel relativo bug. | ||
| - | Se invece vi è arrivata la mail di | + | Se invece vi è arrivata la mail di uno sviluppatore che chiede ulteriori |
| + | informazioni a riguardo, potete rispondere lasciando come Subject | ||
| + | ''Re: pkg/39142'' e come destinatario (To) gnats-bugs@netbsd.org, come se | ||
| + | fosse una semplice email. Anche qui gnats-bugs@netbsd.org si preoccuperà di | ||
| + | accodare la vostra email al giusto PR. | ||
== Conclusioni == | == Conclusioni == | ||
Versione delle 11:17, 25 gen 2009
In questo tutorial impareremo come utilizzare send-pr(1) per inviare un PR.
Nell'esempio che affronteremo invieremo un vero PR, in una situazione reale, nel nostro caso per l'aggiornamento di un pacchetto.
Indice |
Introduzione
PR? Che cosa sono?
I PR (problem report) sono delle segnalazioni di problemi agli sviluppatori NetBSD e/o pkgsrc. Per approfondire si prega di leggere direttamente la pagina PR.
Perché invieremo un PR?
Perché non siamo soddisfatti! :-)
Nel nostro caso abbiamo installato un pacchetto e questo pacchetto su pkgsrc non è aggiornato. Qualcuno potrebbe dire di scaricare ed installare direttamente il tarball, senza utilizzare pkgsrc.
In questo modo però abbiamo diversi problemi:
- Non possiamo gestire il pacchetto in maniera semplice (perché non è in pkgsrc la versione che vogliamo)
- Gli altri utenti pkgsrc (soprattutto chi preferisce i pacchetti binari) sarà costretto a utilizzare una versione del software non aggiornata
Perciò: perché non rendere i nostri sforzi disponibili a tutta la comunità?
Dopo questa riflessione possiamo iniziare.
Individuare il problema
Installiamo un pacchetto da pkgsrc, devel/arena nel nostro caso e dopo un:
$ cd $PKGSRCDIR/devel/arena $ elinks $(make show-var VARNAME=HOMEPAGE)
Scopriamo che l'ultima versione disponibile (e stabile) è la 0.9.13. Prima di proseguire ci accertiamo che anche in pkgsrc-current la versione non è aggiornata (utile solo se utilizziamo una versione stabile di pkgsrc):
NOTA: in tutti gli esempi in realtà il diff di cvs è equivalente a diff -upN come consigliato da The pkgsrc guide, perciò si prega di aggiungere sul vostro ~/.cvsrc la seguente riga
diff -upN
$ cvs diff -rpkgsrc-2008Q1 -rHEAD cvs diff: Diffing . Index: Makefile =================================================================== RCS file: /cvsroot/pkgsrc/devel/arena/Makefile,v retrieving revision 1.4 retrieving revision 1.5 diff -u -p -r1.4 -r1.5 --- Makefile 16 Nov 2006 21:52:19 -0000 1.4 +++ Makefile 12 Jun 2008 02:14:21 -0000 1.5 @@ -1,4 +1,4 @@ -# $NetBSD: Makefile,v 1.4 2006/11/16 21:52:19 agc Exp $ +# $NetBSD: Makefile,v 1.5 2008/06/12 02:14:21 joerg Exp $ DISTNAME= arena-0.9.9 CATEGORIES= devel @@ -8,6 +8,8 @@ MAINTAINER= pkgsrc-users@NetBSD.org HOMEPAGE= http://www.minimalinux.org/arena/ COMMENT= ANSI C like scripting language +PKG_DESTDIR_SUPPORT= user-destdir + GNU_CONFIGURE= yes .include "../../mk/bsd.pkg.mk" cvs diff: Diffing patches
Da come si può osservare l'unica differenza è il supporto DESTDIR, la versione è rimasta la stessa (la variabile DISTNAME non è cambiata). Sempre dal DISTNAME ci accorgiamo che la versione in pkgsrc è la 0.9.9 (e non la 0.9.13).
A questo punto cercheremo di risolvere il problema noi stessi, se non ci riusciremo invieremo un PR senza una risoluzione al problema (tecnicamente Fix).
Risolviamo il problema
Prima di tutto è una buona idea se facciamo un bel backup della versione .orig(inale):
$ cd .. $ cp -r arena arena.orig
In questo modo se qualche cosa andrà storto avremo sempre disponibile arena.orig. In molti casi questo metodo è utile anche per facilitare la creazione delle patch.
Aggiorniamo devel/arena
NOTA: le prossime informazioni possono richiedere qualche conoscenza di pkgsrc, sono state scritte per rendere il tutorial più reale possibile, non vi preoccupate se non capite questa sotto-sezione.
Iniziamo subito a mettere le mani sul Makefile cambiando il DISTNAME e aggiungendo il supporto DESTDIR:
$ $EDITOR Makefile Sostitiamo 0.9.9 con 0.9.13 Aggiungiamo tra COMMENT e GNU_CONFIGURE: PKG_DESTDIR_SUPPORT= user-destdir
Ora proviamo ad installare il pacchetto, dobbiamo cambiare il file distinfo in quanto sicuramente il tarball avrà un diverso checksum:
$ make makesum
Perfetto, ora proviamo ad installare questa nuova versione:
$ make [...] => Applying pkgsrc patches for arena-0.9.13 Ignoring previously applied (or reversed) patch. 2 out of 2 hunks ignored--saving rejects to tests/data/library/foreign.rej Patch /usr/pkgsrc/devel/arena/patches/patch-aa failed ERROR: Patching failed due to modified or broken patch file(s): ERROR: /usr/pkgsrc/devel/arena/patches/patch-aa [...]
Il build non avviene in quanto la patch-aa non è più valida perché il file tests/data/library/foreign.rej è stato modificato, vediamo quindi queste modifiche:
$ make clean
$ make extract
$ cd ../arena.orig
$ make extract
$ diff -u work/arena-0.9.9/tests/data/library/foreign ../arena/work/arena-0.9.13/tests/data/library/foreign
--- work/arena-0.9.9/tests/data/library/foreign 2006-06-27 20:35:49.000000000 +0200
+++ ../arena/work/arena-0.9.13/tests/data/library/foreign 2007-01-07 14:42:21.000000000 +0100
@@ -27,7 +27,7 @@
if (a != 42) exit(2);
-# 3) call C function that takes and returns float
+# 3) call C function that takes and returns C double
a = dyn_call_float(libm, "fabs", -2.5);
@@ -59,4 +59,10 @@
if (!is_dyn_resource(libc)) exit(6);
-print("6 subtests ");
+# 7) call C function takes and returns C float
+
+a = dyn_call_float(libm, "roundf", cfloat(-2.5));
+if (a != -3.0) exit(7);
+
+
+print("7 subtests ");
Leggendo patch-aa possiamo vedere che l'unica modifica che crea il conflitto è il cambiamento del commento # 3) call C, infatti hanno cambiato float con C double, perciò editiamo semplicemente la patch-aa:
$ cd $PKGSRCDIR/devel/arena $ $EDITOR patches/patch-aa Sostituiamo float con C double $ make makepathsum $ make
Se abbiamo modificato la patch correttamente non avremo problemi e la compilazione avverà con successo. Ora possiamo installare il nostro pacchetto aggiornato e fare un pò di testing:
$ cd ../arena.orig $ make deinstall $ cd ../arena $ make install $ arena work/arena-0.9.13/examples/wc.are Makefile
Bene, ora creiamo il file PLIST:
$ make print-PLIST > PLIST
Ottimo, siamo pronti per creare le patch!
Creare le patch
Quali file abbiamo modificato?
Per creare le patch possiamo utilizzare come abbiamo fatto prima il comandi diff di cvs(1), ricapitolando abbiamo modificato i seguenti file:
- Makefile
- PLIST
- distinfo
- patches/patch-aa
Riguardo al Makefile, distinfo e patches/patch-aa non c'è dubbio, le modifiche sono necessarie, ma riguardo a PLIST se gli sviluppatori di Arena non hanno aggiunto nuovi file ad Arena il PLIST non cambia, controlliamolo subito:
$ diff -u ../arena.orig/PLIST PLIST --- ../arena.orig/PLIST 2008-07-07 00:02:02.000000000 +0200 +++ PLIST 2008-07-13 16:43:05.000000000 +0200 @@ -1,4 +1,4 @@ -@comment $NetBSD: PLIST,v 1.1.1.1 2006/10/01 10:48:22 agc Exp $ +@comment $NetBSD$ bin/arena man/man1/arena.1 share/doc/arena/manual.asc
Abbiamo ragione, perciò non dovremo creare la patch per il PLIST, a parte l'Id RCS infatti non è cambiato nulla al PLIST.
Generare le patch tramite cvs(1)
Ora siamo pronti per generare le patch che andremo ad allegare, creiamo una directory in cui mettere queste patch:
$ mkdir ~/arena-prpatches $ cvs diff -rHEAD Makefile > ~/arena-prpatches/patch-mk $ cvs diff -rHEAD distinfo > ~/arena-prpatches/patch-di $ cvs diff -rHEAD patches/patch-aa > ~/arena-prpatches/patch-pa
Ora siamo pronti per inviare il PR!
Inviare il PR
Per inviare il PR utilizzeremo send-pr(1), tuttavia se il vostro MTA non è configurato potote utilizzare l'interfaccia web.
Preliminari
Prima di proseguire impostiamo diverse variabili utili per send-pr(1) (ovviamente possiamo editare queste variabili anche quando invochiamo send-pr, ma per ragioni di comodità le inizializziamo ora), NAME il nostro nome, LOGNAME sarà il nostro indirizzo email e ORGANIZATION (Organizzazione):
$ export NAME="Nome Cognome" $ export LOGNAME=il_nostro_indirizzo_email@provider.bo $ export ORGANIZATION="NetBSD Italia"
Il nome e l'organizzazione può anche essere salvata su un file, in questo modo:
$ echo "Nome Cognome" > ~/.fullname $ echo "NetBSD Italia" > ~/.organization
Invochiamo send-pr(1) e compiliamo il PR
Iniziamo a riempire il PR!
$ send-pr
Il primo campo vuoto è il Subject (soggetto dell'email), nel nostro caso:
Subject: Update devel/arena to 0.9.13
Il secondo campo da riempire è Confidential, ovvero se le sezioni diverse dal Subject e dalla Synopsis (sinossi) NON verranno pubblicate, nel nostro caso vogliamo che queste informazioni siano disponibili a tutti, perciò:
>Confidential: no
Ora editiamo Synopsis (sinossi), ovvero una piccola descrizione del problema:
>Synopsis: devel/arena package isn't updated (version 0.9.13)
Ed ora il grado di severità, non-critical se il problema non è molto grave, serious se il problema è abbastanza grave o se è critical ma abbiamo una soluzione disponibile, critical altrimenti:
>Severity: non-critical
La priorità, bassa (low), media (medium) o alta (high):
>Priority: low
Poi la categoria:
>Category: pkg
La tipologia del problema:
>Class: change-request
Inoltre se il problema è collegato al kernel o userland bisogna specificare e accertarsi che Release ed Environment siano corretti.
Una volta specificati questi campi passiamo alla descrizione del problema (Description):
>Description: The devel/arena pkgsrc's (-2008Q1 and HEAD) version is 0.9.9 and Arena 0.9.13 is out, so it could be updated.
Bisogna inoltre specificare come ripetere il problema (How-To-Repeat):
>How-To-Repeat: $ cd $PKGSRCDIR/devel/arena $ make show-var VARNAME=DISTNAME and/or $ cd $PKGSRCDIR/devel/arena $ make install $ arena -V
Ed ora come risolvere il problema (Fix):
>Fix: Please apply the attached patches that update devel/arena to 0.9.13 version, thank you!
Per allegare le patch se stiamo utilizzando vi(1) possiamo utilizzare
il comodo comando :read, ad esempio:
:read patch-mk
Confermare?
Una volta chiuso l'editor ci apparirà questo messaggio:
a)bort, e)dit or s)end?
Se siamo sicuri di inviare: s, se invece vogliamo controllare che sia tutto a posto possiamo rieditare il testo tramite e.
Una volta inviato possiamo leggere:
send-pr: problem report sent
Congratuliazioni!
Ed ora?
Ora bisognerà aspettare che qualche sviluppatore NetBSD o pkgsrc chiuda il PR, nella maggior parte dei casi il problema viene risolto in tempi brevi (brevissimi se è presente il Fix).
Di norma dopo qualche diecina di secondi o minuti dovrebbe arrivarci un email di conferma con un Subject di questo genere: Re: pkg/39142: Update devel/arena to 0.9.13 e infine altre email da parte di sviluppatori riguardo allo stato del PR.
Per leggere tutte le email riguardo al nostro PR: 39142
Aggiungere maggiori informazioni ad un PR
Se credete di avere ulteriori informazioni sul PR di cui siete venuti a conoscenza solo dopo aver già fatto il report, o semplicemente che vi siete dimenticati di accludere potete rispondere al messaggio di conferma che vi è arrivato da gnats-bugs@netbsd.org. Provvederà gnats-bugs@netbsd.org stesso (leggendo il subject) ad aggiungere le informazioni nel relativo bug.
Se invece vi è arrivata la mail di uno sviluppatore che chiede ulteriori informazioni a riguardo, potete rispondere lasciando come Subject Re: pkg/39142 e come destinatario (To) gnats-bugs@netbsd.org, come se fosse una semplice email. Anche qui gnats-bugs@netbsd.org si preoccuperà di accodare la vostra email al giusto PR.
Conclusioni
In questo tutorial abbiamo imparato come inviare un PR, inviare PR è importante, oltre ad essere un modo per contribuire a NetBSD e/o pkgsrc è anche un modo per rendere il software più stabile, sicuro, semplice e corretto.
