Inviare un PR

Da Wiki di NetBSD Italia.

Versione delle 17:21, 13 lug 2008

In questo Categoria:Tutorial: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.

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 Categoria:Variabili:variabile [[:DISTNAME:${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 po' 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).

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.