E così alla fine sono riuscito a finire il porting di bulbcalculator, dopo anni diversi anni di lavoro. Non che ci abbia impiegato cos’ tanto, ma il tempo era quello che era. In più ovviamente nel mezzo ho fatto un po di altre cose. Tutto sommato però l’importante è esserci riuscito.
A questo punto posso cominciare a pensare a come evolverlo. Suggerimenti ?
Si può scaricare dal sito su gitorious
Rieccomi a fare qualcosa per il bel sito One Liners.
Questa volta è uno scriptino per effettuare il purge di tutti i file di configurazione dei pacchetti rimossi. Non è legato ad una shell specifica, io ho provato sotto Tcsh, ma è bello ed elegante:
dpkg -l | grep "rc " | awk '{FS="\n"}{ print $NF}' | awk '{FS=" "}
{print $2}' | xargs dpkg --purge Da scrivere tutto su una linea ovviamente. Spero serva a qualcuno
Come già detto sul sito, lo script di suo potrebbe prendere dentro anche i pacchetti che finiscono per “rc”, tipo sysv-rc, ma non ci dovrebbero essere problemi
Update: Elena suggerisce che usando grep "^rc " il bug viene risolto.
Dopo essermi bruciato i db MySQL (di cui ovviamente non avevo un backup 
) a causa di un aggiornamento poco ortodosso, mi sono ingegnato su come recuperare almeno la struttura delle tabelle. Cercando un po’ in giro, ho trovato il modo di recuperarla partendo dai file .frm creati da MySQL. Funziona ovviamente se questi file sono a disposiozione.
I passi sono piuttosto semplici:
Questa procedura permette di recuperare almeno la struttura delle tabelle del database, i dati sono ovviamente persi, ma almeno è meglio di niente.
Per portare avanti lo sviluppo che faccio su BugsEverywhere, mi sono installato un server Bazaar per pubblicare i branch su cui lavoro (al momento solo l’export in html)
Comunque, seguendo i passi di questo tutorial, si riesce ad installare un server bazaar accessibile via http in lettura e via sftp in scrittura.
Riporto qui il procedimento a futura memoria
Se non sono già tutti installati, installare i seguenti pacchetti:
apt-get install bzr bzrtools python-paramiko openssh-server ssh
dopodichè si può creare un utente che verrà usato per accedere in scrittura al repository
useradd --create-home --home-dir /home/bzr --shell /usr/lib/sftp-server bzr
Ovviamente la home-dir può essere diversa. Adesso bisogna impostare una password per l’utente bzr con il solito comando
passwd bzr
e aggiungere sftp-server nella lista delle shell valide con
echo '/usr/lib/sftp-server' >> /etc/shells
A questo punto si passa alla configurazione della parte web che consetirà l’accesso in sola lettura. Con lighttpd, basta aggiungere queste due righe al file di configurazione e riavviare il server:
server.dir-listing = "enable" alias.url += ( "/bazaar/" => "/home/bzr/")
Ovviamente si può impostare il server web in modo che consenta l’accesso solo a certi IP o con la password, nel caso non si voglia un repository pubblico. Per queste opzioni consiglio di rifarsi alla documentazione del server web usato.
La configurazione del server a questo punto è conclusa ed è pronto per essere testato.
Il test si effettua con il solito sistema di creare un repository di prova sulla macchina di sviluppo, caricarlo sul repository remoto e poi provare a scaricarlo in lettura, ecco i passi da effettuare:
bzr whoami "uno qualsiasi <pr@mia_mail>" mkdir project1 cd project1 mkdir test touch test1.txt test2.txt test3.txt test/test4.txt bzr init bzr add bzr commit -m "test"
creano il repository in locale, mentre il comando
bzr push --create-prefix sftp://bzr@server/home/bzr/Test
oppure
bzr push --create-prefix sftp://bzr@server/~/Test
lo carica sul server. Ovviamente per poter accedere in scrittura bisogna conoscere la password dell’utente bzr
Se tutto è andato bene, con il comando
bzr get http://server/bazaar/test
dovrebbe essere possibile scaricare il repository in locale, in sola lettura.
Questo è tutto. Buon lavoro
Dato che sono finito tra gli autori di Bugs Everywhere, ho messo in piedi un nuovo sito in inglese. Li parlerò praticamente solo di software e la lingua ufficiale sar’ l’inglese.
Come anticipato, la mia patch a Bugs Everywhere è stata accettata a tempo di record, anche se con una piccola modifica per rendere la sintassi omogenea con il resto. 
La patch di suo è una piccola aggiunta al comando “target” di BE e consente di elencare tutti i target presenti nel repository. Un target banalmente può essere visto come una milestone o un tag. L’idea mi era venuta notando che altri comandi avevano la possibilità di visualizzare una lista degli elementi presenti o predefiniti (tipo la severità o lo stato del bug).
A questo punto, visto che sembra divertente, mi sa che be2html (il tool che estrae le informazioni da un repository BE e genera una serie di pagine html) al posto di essere un programmino a se stante, lo farò diventare (se nessuno avrà nulla in contrario) un comando di BE.
Su istigazione di questa persona, mi sono messo a giocare con i BTS distribuiti.
I BTS distribuiti non hanno un database centrale, copiando quindi la logica dei vari programmi di gestione delle versioni (VCS, da Version Control system) distribuiti come git, mercurial, darcs etc.
Come i VCS distribuiti si contrappongono ai VCS centralizzati per la mancanza di un repository cerntrale dove vengono memorizzare le revisioni e così via, allo stesso modo i BTS (Bug Tracking System) distribuiti non hanno un unico database in cui vengono memorizzate le richieste e i bug.
Potremmo dire che se un software tipo bugzilla o flyspray è il compagno ideale di CVS o subversion, un BTS distribuito è il compagno ideale di Git o Bazaar.
Finita questa breve premessa, vediamo di passare ad analizzare gli eventuali vantaggi e svantaggi di questi sistemi, tenendo presente che ovviamente non è un’analisi completa.
Dopo aver valutato diversi sistemi di BTS distribuiti, la mia scelta è caduta su Bugs Everywere, per due semplici ragioni:
A dire il vero, il primo lo si vede da sè, mentre il secondo nasce dall’uso. L’altro candidato era Ditz. Altri sistemi ci sono, ma non mi hanno impressionato.
Come per i VCS distribuiti il vantaggio maggiore è quello di poter fare tutto off-line. Si può quindi ad esempio aggiungere un bug, modifcarne un altro e chiuderne un terzo senza il bisogno di essere on-line. Questo è il completamento ideale per un VCS tipo git, in quanto rende indipendente lo sviluppatore dall’essere sempre on-line anche per il lato BTS.
Ovviamente ci sono anche degli svantaggi: ad esempio, sono mediamente più complessi da usare per l’utente finale, visto che di solito hanno un’interfaccia testuale e accompagnano i sorgenti (e non gli eseguibili).
Una cosa interessante è che i repository dei bug vengono generalmente trattati come dei qualsiasi file del progetto e quindi i vari elenchi possono essere gestiti in maniera naturale.
Tutti i problemi sono però superabili in un modo o in un altro. Ad esempio Ditz ha un generatore di pagine html statiche per consentire di pubblicare lo stato del progetto via web.
Come ho già detto la mia scelta è caduta su Bugs Everywere, con il quale traccio i bug di Chiamami (una semplice agenda telefonica).
Il vantaggio principale di BE è la migliore integrazione con git (il VCS che uso), anche se a scapito di una peggiore interfaccia rispetto a Ditz.
Guida veloce a Bugs Everywhere
Adesso una veloce e minuscola guida all’uso di BE per la gestione di un progetto. Lanciando BE senza parametri otteniamo l’elenco dei comandi supportati.
galactica:~/Devel/Test2> be Bugs Everywhere - Distributed bug tracking Supported commands be assign Assign an individual or group to fix a bug be close Close a bug be comment Add a comment to a bug be diff Compare bug reports with older tree be help Print help for given subcommand be list List bugs be new Create a new bug be open Re-open a bug be remove Remove (delete) a bug and its comments be set Change tree settings be set-root Assign the root directory for bug tracking be severity Show or change a bug's severity level be show Show a particular bug be status Show or change a bug's status be target Show or change a bug's target for fixing galactica:~/Devel/Test2>
Si nota abbastanza facilmente che sono abbastanza simili a quelli di un qualsiasi BTS tradizionale.
Un problema che ho riscontrato (ma forse sono io che sbaglio) è che mentre ovviamente non esistono elenchi di target predisposti al contrario di status e severity, non c’è un modo di avere l’elenco dei target già presenti, e questo su progetti un pò più grandi del piccolo progetto personale potrebbe essere un problema. Dopo un rapido scambio di mail con l’autore, questa funzionalità verrà inserita in una prossima versione.
Inizializzare il repository
Partendo dal presupposto di avere già un repository git, per inizializzare il repository be si usa il comando
be set-root
e se tutto va bene il sistema ritorna
galactica:~/Devel/Test2> be set-root Using git for revision control. Directory initialized. galactica:~/Devel/Test2>
Si può notare che BE riconosce automaticamente il fatto che si usa git.
Una nota: il repository git deve avere nella sezione config i valori si user.name e user.email settati, altrimenti il comando fallisce.
Lavorare con i bug
Per aggiungere un nuovo issue, si usa il comando new
galactica:~/Devel/Test2> be new "Test" Created bug with ID 90c galactica:~/Devel/Test2>
L’elemento viene creato usando i valori di default del sistema. Creato l’elemento, è possibile modificarlo usando i vari comandi per impostare la gravità, a chi è assegnato, la deadline per la quale si deve chiudere (in termini di versione, ma dato che la versione è una stringa arbitraria, potrebbe anche essere una data) o aggiungere una descrizione più estesa del problema/richiesta.
Ad esempio, per alzare la gravità del bug appena inserito da minor, che è il default, a serious si usa il comando severity
be severity 90c serious
dove 90c è l’id dell’elemento.
Possiamo vedere i dettagli del bug con il comando show
galactica:~/Devel/Test2> be show 90c
ID : 90cc54c6-d3e3-4562-b340-9c50d8d9ca31
Short name : 90c
Severity : serious
Status : open
Assigned :
Target :
Creator : gian <gian@grys.it>
Created : Thu, 16 Apr 2009 23:01 (Thu, 16 Apr 2009 21:01:05 +0000)
Test
--------- Comment ---------
Name: 90c:1
From: gian <gian@grys.it>
Date: Thu, 16 Apr 2009 21:11:53 +0000
Aggiungere un commento
galactica:~/Devel/Test2>
.Per chiudere un bug, si usa abbastanza ovviamente il comando close
be close 90c
Se invece abbiamo già un elendo di bug e lo vogliamo visualizzare, allora ci viene in aiuto il comando list
galactica:~/Devel/Test2> be list 90c:os: Test 981:om: Test galactica:~/Devel/Test2>
Il formato e’ questo:
Questo è tutto quello che serve per poter usare Bugs Everywhere nel lavoro di tutti i giorni.
Ho messo sul sito, una prima versione di Chiamami, una semplice agenda telefonica. Quanto prima farò una pagina di documentazione. Al momento è possibile scaricare i sorgenti.
Nel tempo libero ho messo insieme una prima versione. QtTumblr è un programmino scritto in python/qt4 per postare su Tmblr.com senza la necessità di usare un browser. Non so quanto sia utile, ma è stato un ottimo esercizio.
In questo periodo un po’ pieno, sto mettendo in campo un po’ di software:
questi due mi servono per studiarmi un po’ meglio (o più precisamente ripassarmi) il C e il C++, sperando che mi possano servire per cambiare lavoro
Un altro software a cui sto cominciando a pensare è un aggeggio per poter postare su Tumblr senza la necessità si usare un browser, visto che le api le forniscono, non dovrebbe essere difficile mettere in piedi un sw in python/qt4… se solo il designer funzionasse con emerge desktop…
Piccolo corso su come creare un nuovo repository git su server remoto.
Prima di tutto si crea la directory che contiene il progetto in locale e si inizializza
mkdir test_project cd test_project git init git remote add origin git@YOUR_SERVER_HOSTNAME:test_project.git
A questo punto si può lavorare nella directory come al solito.
Quando si decide di aver finito, si aggiungono i file con
git add .
e si committa tutto il lavoro
git commit -a
e poi si esegue il push con
git push origin master:refs/heads/master
e da qui il repository è pronto.
Questo approccio si può usare anche per importare dei sorgenti, basta scompattarli, entrare nella directory e dare il comando
git init
e poi seguire il resto dei passi.
Ieri sera mi sono fatto l’ultimo update sul portatile, giusto per portare le Qt alla versione 4.4.0 (quella con webkit, Widget On Canvas e via dicendo). Quindi lo sviluppo di QtNotes e OpenBoat riprenderà da li, anche se devo ancora aggiornare il widget OpenGL che uso e di cui c’è una vuova versione.
Ho appena eliminato lo spazio su assembla.com di SailForLinux.
La decisione è dovuta al fatto che in ogni caso non avrei il tempo di seguirlo, oltre ad essere sostanzialmente inutile al momento, dato che per quest’anno il campionato non si fa. Se mai servisse riprenderò in mano i sorgenti sul mio repository git e bts su grys
…conservando la storia delle commit.
L’operazione è banale. Sono 3 semplici passi
git clone server:repository.git
git remote add origin utente@server:repository
git push origin master:refs/heads/master
Ed il gioco è fatto, buon lavoro
Ora che abbiamo il nostro server attivo, bisogna usarlo. I passi da fare sono i seguenti, facendo molta attenzione a non fare confusione con le chiavi pubbliche ssh, altrimenti non funziona nulla:
1. clonare il repository gitosis-admin git clone git@SERVER:gitosis-admin.git
2. modificare il file gitosis.conf per aggiungere un blocco simile a quello presente, ad es.
[group devel]
writable = vtf QtRegExp
members = gianluca
3. committare le modifiche e fare il push del repository.
Se si vuole aggiungere una chiave pubblica di un nuovo utente con diritti di scrittura, basta copiare la chiave ssh (pubblica) nella directory keydir, aggiungere il file con git add e poi solita commit e push. Attenzione che il nome del file della chiave indica il nome dell’utente. Nel caso sopra quindi, avendo abilitato un utente “gianluca”, avrà in keydir un file gianluca.pub
