Parlo della mia! Praticamente ho speso tempo, forze ed energia per capire come mai uno stupido esempio che utilizzava gnome-keyring si rifiutava di compilare fallendo miseramente al momento del linking poiché mancava un simbolo nella relativa libreria.

All’inizio stupore “non può essere” poi inizio con objdump a vedere se questo simbolo era presente o meno, ma niente. Quindi apro il caro xchat e preso da dubbi comincio a rompere su #gnome #gnome-hackers e #gnome-debian, chiedendo se objdump visualizzasse tutti i simboli esportati in una libraria o per qualche ragione a me ignota escludesse le variabili globali.

Beh qualcuno mi ha aiutato, ma praticamente sono rimasto con il dubbio se objdump fosse il tool adatto e sono andato fuori strada poiché ho subito pensato ad un bug della mia distribuzione. Non rimaneva che scaricare i sorgenti da svn e provare direttamente quelli.

Stesso identico errore, quindi posto l’esempio su xchat e come prevedibile, grazie all’aiuto di qualche smanettino verifico che gentoo ubuntu e mandriva falliscono tutte. A questo punto il problema deve essere upstream.

Quindi prima devo chiarire se objdump -T fa il suo lavoro o meno poi iniziare a smanettare suo sorgenti, ma da dove partire dato che sembrano corretti? Beh scrivo un programma che simula la struttura di quella parte della libreria e raggiungo la consapevolezza che

1. objdump fa bene il suo lavoro e lo fa anche su file .o ed eseguibili ed ha anche un sacco di amici come nm
2. che grep come cosigliato da qualcuno non va bene perché può dare falsi positivi (simboli di debug)

Con queste nuove armi indago sul risultato della compilazione della versione in trunk ed arrivo alla conclusione che nel file gnome-keyring.o sto benedetto simbolo c’è, ma poi alla fine nell’immagine .so scompare.

Quindi non può essere gcc, ma qualche altra cosa… e bang: libtool. A questo punto è diventato tutto più facile e dopo aver dato un occhio ad header elf, scritto programmi, il fix si è ridotto ad una riga in Makefile.am!

http://bugzilla.gnome.org/show_bug.cgi?id=522651

Comunque era da tanto tempo che non provavo questa sensazione di novità mista a curiosità e mi è proprio piaciuta!

La prima volta in una applicazione upstream gnome non si scorda mai:

http://svn.gnome.org/viewvc/metacity?view=revision&revision=3615

Ho riabilitato compiz di nuovo e per gioco! Non ci sarebbe nulla di cui scrivere se non fosse per un dettaglio: è usabile sul mio pc.

:~$ cat /proc/cpuinfo
……..
model name : Intel(R) Pentium(R) 4 CPU 1.50GHz
stepping : 2
cpu MHz : 1495.272
cache size : 256 KB
……..

con una semplice ATI 9200SE che non può nemmeno andare a 8x perche’ il mio bus AGP e’ troppo vecchio!

Di solito tutte le volte che mi è capitato di abilitare compiz, dopo pochi giorni di utilizzo ritornavo al fido metacity poichè le animazioni di minimize/maximize ed il resize delle finestre erano leggermente lenti.

Al contrario, questa volta, ho voluto approfondire, ho lasciato XAA per la più nuova EXA e la differenza si è vista immediatamente. Il tutto grazie a questo commento e qualche prova sul campo.

Un’ultima cosa: AGPFastWrite nel mio caso blocca tutto, uomo avvisato…

Come al solito nello spirito di essere il piu’ possibile indipendente da Windows anche per le cose più strane, oggi ho dedicato la giornata (e parte della notte) al mio nuovo lettore mp3 (del quale non ho mai parlato).

L’obiettivo era quello di poter effettuare l’upgrade del firmware senza utilizzare windows. Quindi mi sono messo al lavoro e sorpattutto grazie ai forum / wiki di rockbox sull’argomento creative mi sono fatto un’idea di quello che serviva:

1. Utility per estrazione firmware dall’exe windows che è possibile scaricare dal sito creative
2. Programma per trasmettere il firmware allo Zen

Il risultato è che dopo qualche oretta di ricerche e porting di programmi windows etc etc riesco ad avere un software che svolge egregiamente il compito 1 ed un altro che riesce a fare l’upload di un file tramite libmtp. Obiettivo raggiunto!

A questo punto faccio una bella pausa per la cena, poi un po’ di tv ed infine decido di buttare un occhio al forum per vedere se ci sono novita’. Trovo che zook ha appena pubblicato una nuova e piu’ completa versione delle sue utilita’.

Macino, compilo, qualche piccolo riadattamento e mi metto a fare delle prove con zen_crypt, più per curiosità che per altro.

Con grande sorpresa, dopo qualche tentativo, scopro la chiave con la quale è criptato il programma che gira nello ZEN (il file TL) e scorrendolo con un editor esadecimale becco anche il codice HMAC per firmare i firmware ed uploadarli cosi’ al dispositivo.

Bene si puo’ dire che lo Zen 4GB è un passo più vicino a RockBox (2 chiavi su 3)! Ora manca solo quella del programma di rescue (FRESC) che però credo sia la più difficile da scovare.

Come andrà a finire lo si potrà leggere qui.

Breve ed interessante sessione di debug di mtpfs con valgrind e alleyoop!
Come si evince dal secondo tentativo, nessun leak rimasto a parte qualche segnalazione (spero spuria) di libfuse.

Nota: se provando a debuggare un filesystem fuse, valgrind vi risponde con un bel:

fuse: failed to exec fusermount: Permission denied

Provate a togliere l’attributo sticky sia da /usr/bin/fusermount che /bin/mount ed eseguite il tutto da root. Una volta terminato il debug ricordatevi di rimettere tutto a posto.