Ancora su esperienze nel campo della correzione di errori in software open-source.
Quanti si sono trovati di fronte ad errori software?
Quanti hanno provato a comprenderne la natura e correggerli?
Quanti hanno semplicemente provato a segnalarli a chi di dovere?
Ebbene noi siamo nell’insieme unione dei precedenti insiemi: per dirla in parole povere “le abbiamo sperimentate tutte”.
In perfetto stile iLinux parliamo naturalmente di quanto possiamo aver vissuto nel nostro sperimentare tecnologie open-source (sia in campo professionale che per puro diletto), trascurando quanto attiene al mondo delle software house “con blasone” e i loro livelli di qualità del software (ivi compresa Apple, si intende).
Trascuriamo dunque non per omissione, ma per impossibilità di intervenire concretamente nel ciclo produttivo; sottolineeremo invece del mondo open-source un certo carattere “closed” che in questi anni abbiamo visto affiorare ogniqualvolta si è tentato di intervenire nel ciclo produttivo di qualche componente software.
Primi passi
La prima esperienza nel cercare di intervenire nel ciclo produttivo del software “open” fu nel lontano (!) 2004, quando, per ragioni professionali, si stava lavorando ad una distribuzione linux personalizzata basata su una RH7.3 (era epoca di RH8, da tutti ritenuta assolutamente instabile, quindi si operò una scelta conservativa) per una istituzione pubblica italiana.
Dovendo entrare in produzione su server IBM xSeries 200, 205 e 220, i test di collaudo si concentrarono essenzialmente su queste tipologie hardware; ma il bugs è stato insidioso e si è celato per circa un anno dalla messa in produzione della prima istanza della distribuzione, comparendo quando ormai avevamo in esercizio più di 200 server (!)
L’insidioso bugs si celava nella mappatura delle tastiere IBM per la lingua italiana, non consentendo la produzione della ‘Q’ (maiuscola) mediante Caps Lock (pur consentendola mediante Shift). Questo problema va da se è insidioso anche perché legato allo “stile” di digitazione dell’operatore: ed in effetti è stata proprio la segnalazione di uno delle centinaia di operatori a segnalare il problema.
La mappa in questione è data dal file ” /lib/kbd/keymaps/i386/qwerty/it-ibm.map.gz”, all’epoca distribuito nel pacchetto “console-tools -19990829-40”; il tasto corrispondente alla lettera ‘q’ ha codice 16, e lo troviamo descritto come segue:
keycode 16 = qQat
Leggiamo il manuale di “keymaps”, che citiamo:
Each keysym may be prefixed by a ’+’ (plus sign), in wich case this keysym is treated as a “letter” and therefore affected by the “Cap sLock” the same way as by “Shift” (to be correct, the CapsLock inverts the Shift state). The ASCII letters (’a’-’z’ and ’A’-’Z’) are made CapsLock’able by default. If Shift+CapsLock should not produce a lower case symbol, put lines like …
La definizione data per il codice 16 contraddice nei fatti l’assunto, impedendo il comportamento tramite CapsLock del tasto 16.
Seguendo il manuale applichiamo la seguente modifica (aggiungiamo un ‘+’ prefisso):
keycode 16 = +qQat
e tutto comincia a funzionare come deve.
Nell’intestazione del file “it-ibm.map” troviamo:
# Keyboard map for italian IBM(c) PC keyboards # Dec 1994 - Leonardo Valcamonici /CASPUR # ---------------------------------------------------------- # Please report bugs & improvements to valcamonici@caspur.it
Il caso vuole che il quel periodo Paolo Tassotti (friend del nostro sito e parente di qualcuno di noi) collaborava a delle ricerche proprio presso il CASPUR e confermava in quell’ente la presenza in attività del nominato Valcamonici. Decidiamo dunque di porci in contatto con lui anche con la mediazione (“raccomandazione”? … vezzo italico di difficile estinzione) di Paolo, e di descrivere bug e possibile soluzione.
Lo scambio epistolare ha termine in data “Fri, 08 Oct 2004 14:41:27 +0200”, con la seguente:
Grazie a tutti voi. Leonardo Valcamonici -- +======================================================================+ | Leonardo Valcamonici | | CASPUR | | Italian Interuniversities Consortium for Supercomputing Applications | | Via dei Tizii, 6b - 00185 Rome (Italy) | +======================================================================+ | e-mail: l.valcamonici@caspur.it voice : [OMISSIS] | | mobile: [OMISSIS] fax : [OMISSIS] | +======================================================================+
(Abbiamo censurato ulteriori riferimenti per rispetto della privacy, in quanto non siamo stati autorizzati alla pubblicazione, benché, essendo la sua firma standard, crediamo siano di pubblico dominio.)
Siamo stati contenti di aver in qualche modo collaborato (per carità, in una frazione infinitesimale) al perfezionamento del software linux, noi di iLinux e tutti i protagonisti dello sviluppo del progetto di distribuzione personalizzata RH7.3 (per inciso, tale distribuzione è ancora in esercizio su +170 server xSeries, e non è poco!).
Il tempo è passato e qualcosa deve essere andato storto. Infatti le ultime analisi ci dicono che le versioni del file “it-ibm.map” presente nelle ultime versioni RedHat e Fedora presentano analogo problema:
Distro Pacchetto
FC7 kbd-1.12-22.fc7
FC8 kbd-1.12-27.fc8
FC10 kbd-1.12-31.fc9
RHEE4 kbd-1.12-2
RHEE5 kbd-1.12-19.el5
Altre prospettive
Passano anni e ci troviamo a fare esperimenti su altre tecnologie open-source, ed in particolare queste molto interessanti per la nostra “iLinux-filosofia”: ObjectiveC.
La genesi di questa nuova esperienza con i bugs nel software linux l’abbiamo descritta nel precedente articolo (“Bugs e solitudine”), in ideale proseguimento con tutti gli articoli dal vario tono cervellotico che accompagnano le nostre esperienze di ibrizazioni.
Il nuovo bugs nasce nel contesto di ibridazione tra C++ e ObjectiveC con alcuni frammenti di codice per capire appieno le potenzialità e possibilità di GCC in questo campo, certamente con un occhio a quanto sarebbe avvenuto internamente a XCode (corazzato anche lui con GCC).
In effetti il bug è insidioso, ma replicabile in modo semplice, in realtà talmente semplice che una sola #import potrebbe ricrearlo. Ma diamo dimostrazione con un sorgente estremamente semplificato (rispetto a quello che ci ha mostrato per la prima volta il bugs e che abbiamo citato nel precedente articolo), ma completo e funzionante:
#import <Foundation/Foundation.h>
int main()
{
printf("Hello, World!\n");
return 0;
}
Diamo nome a questo sorgente “example.mm” e compiliamo con:
g++ -lobjc -lFoundation example.mm
ottenendo il bug:
/usr/include/real_exception_file.h:68: error: expected identifier before ‘class’ /usr/include/real_exception_file.h:68: error: expected `:' before ‘;’ token /usr/include/real_exception_file.h:68: error: expected identifier before ‘;’ token
Perché di bugs si tratta, non di un nostro errore (sfido a trovare un errore in un codice minimale quale il precedente!).
La riga indicata è parte di una dichiarazione nel file “real_exception_file.h”:
@interface NSException (Extensions) - (BOOL)exceptionIsKindOfClass:(Class)class;
Per quella “piccola” esperienze che abbiamo di linguaggi di programmazione e tenologie a corollario, individuiamo il problema nell’uso improprio di una “parola chiave” del C++ in una dichiarazione che il compilatore C++ dovrà interpretare durante l’analisi del sorgente (anche se preprocessato da ObjectiveC).
Così, come abbiamo detto nel precedente articolo, abbiamo registrato il bugs su https://bugzilla.redhat.com/show_bug.cgi?id=467165.
Quello che nel precedente articolo non potevamo scrivere è il proseguimento della storia: un tal John Poelstra (<poelstra@redhat.com>) ha chiuso la segnalazione come “WONTFIX” adducendo la seguente motivazione:
--- Comment #1 from John Poelstra <poelstra@redhat.com> 2008-10-17 19:54:06 EDT --- Thank you for your bug report. We are sorry, but the Fedora Project no longer maintains this version of Fedora. Please upgrade to the latest version and reopen this bug against that version if this bug exists there. As a result we are setting this bug to CLOSED:WONTFIX -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug. -----------------------------------
Ok, ci possiamo stare. Fedora è un progetto in continua evoluzione, dunque non si possono consentire la manutenzione di versioni ritenute superate.
Certo la cosa che non ci è proprio gradita è che il pacchetto libFoundation-devel (che contiene il file portatore del bug) sia in versione 1.1.3-10.fc6, che evidenzia come sia un file prodotto in origine per la distribuzione Fedora Core 6 e non ulteriormente trattato.
E sia.
Ci riproviamo con una distribuzione Fedora Core 8, che però (incredibilmente) fornisce la medesima versione di pacchetto della FC7 e dunque della FC6.
Segnaliamo nuovamente il bug indicando anche questa anomalia nel re-packaging. Lo facciamo con la segnalazione: https://bugzilla.redhat.com/show_bug.cgi?id=469028 del 2008-10-29.
Forse siamo sfortunati, o forse semplicemente poco aggiornati; la segnalazione viene scartata in qualche modo con un messaggio generato automaticamente che pressappoco dice quanto segue:
La Fedora 8 è giunta al termine del ciclo di vita, tra 30 giorni verrò dichiarata obsoleta, la segnalazione di bugs verrà dichiarata WONTFIX, se si intende produrre una patch e mantenere per questo aperta la segnalazione del bugs cambiare la versione della segnalazione ad una versione maggiore di Fedora.
Non ci arrendiamo, ma neanche seguiamo direttamente quanto indicato del messaggio (non diamo mai retta alle cose automatiche!!!).
Con una distribuzione FC10 fresca di download creiamo il nostro esperimento in un bel contesto virtuale (utilizzando VirtualBox sun nostro iMac).
Le cose non cambiano affatto, e anche in questo caso abbiamo una versione retrodatata della libreria Foundation (libFoundation-devel-1.1.3-11.fc9.i386).
Segnaliamo il tutto in una nuova registrazione: https://bugzilla.redhat.com/show_bug.cgi?id=475754 in data 2008-12-10.
Conclusioni? Forse qualcuna.
Il progetto GNUStep e la annessa libreria libFoundation, benché entrata nel novero dei progetti seguiti dalla distribuzione Fedora, non è certamente posto su un gradino elevato. E’ un poco trascurato, e di questo ci dispiaciamo molto.
Ma c’è una cosa che ci dispiace maggiormente: sembra (ma forse è solo dovuto al nostro minimo coinvolgimento) che la comunità open-source sia poco sensibile alle segnalazioni e sollecitazioni che vengono al di fuori della comunità. Noi certamente siamo “fuori dal giro”, come si dice, ma la comunità ci appare un poco “closed”.
Ma forse è solo apparenza.
Speriamo almeno che l’ultima segnalazione porti qualche frutto. Seguiremo il caso.