Compilare gnome-shell da git su Fedora 14

Da qualche settimana seguo la newsletter di Gnome Shell in attesa dell’uscita dell’attesissimo Gnome 3 prevista nei primi giorni di Aprile. Nel frattempo mi è venuta voglia di provare il nuovo ambiente ma purtroppo la versione fornita con Fedora 14 è molto vecchia e non ha senso usarla, abituandosi ad un modo di lavorare che non sarà quello definitivo.
Cercando in giro sembra che l’unica possibilità sia avviare la live di Fedora 15 alpha, che includerà il nuovo desktop di default, oppure la Suse fornita dal progetto Gnome, ma in questo caso non avremmo a disposizione le ultimissime novità che giornalmente vengono inserite nei sorgenti in sviluppo. Inoltre potremmo fare solo un veloce test in live.
In alternativa è possibile seguire i passaggi suggeriti direttamente dagli sviluppatori per compilare manualmente i programmi necessari con l’intero parco di dipendenze richieste. Niente paura perchè seguendo queste istruzioni si creerà di fatto una sandbox da cui sarà possibile avviare (ed usare) gnome-shell senza intaccare minimamente il sistema in uso. Era proprio quello che cercavo!
La traccia da seguire per la compilazione è scritta nella pagina del progetto (http://live.gnome.org/GnomeShell).
Non scriverò qui la sequenza dei comandi in quanto è gia scritta nella pagina di gnome ed è molto semplice ma riporterò solo qualche indicazione sui passaggi da seguire e la soluzione dei problemi che ho incontrato.
Con “curl” si recupera lo script principale che si occuperà di verificare la distribuzione in uso e delle eventuali dipendenze necessarie alla compilazione.
Eseguendo il “gnome-shell-build-setup.sh” ho installato tutti i pacchetti richiesti tranne due di cui non esisteva traccia nei repository di Fedora (libjpeg-devel e gettext-autopoint). Per il primo ho dovuto sostituire il nome nel pacchetto nel file .sh perchè la F15 non usa più questa libreria ma usa la “libjpeg-turbo-devel” (riga 116 dello script). Per il secondo stesso discorso, il programma autopoint è contenuto in “gettext” e non in “gettext-autopoint” per cui ho sostituito il nome del pacchetto nel file (riga 130).
Ho tralasciato il comando “sudo rm -rf /usr/lib*/*.la” in quanto non si fa riferimento a Fedora.
A questo punto non ci resta che lanciare il:

jhbuild build

ed andare a preparare il pranzo: il programma si occupa di scaricare e compilare uno per uno i sorgenti necessari (sono 40!!); naturalmente una buona connessione internet è auspicabile.
L’unico problema che ho incontrato è stato allo scaricamento di “clutter” di cui non è stato possibile fare il download. Googlando un po’ in rete ho scoperto che c’è un problema con il download tramite protocollo git da sito per cui è necessario scaricare a mano i sorgenti relativi prima di continuare. In una nuova shell eseguire:

cd ~/gnome-shell/source/
git clone http://git.clutter-project.org/clutter

A questo punto è possibile continuare la compilazione precedente rispondendo 1 alle domande poste dallo script. Non ho incontrato altri problemi e il tutto si è conluso con un attesissimo *** success *** [40/40].
Prima di avviare avviare il nuovo desktop dalla sandbox ho dovuto cancellare una libreria non necessaria che generava questo errore:

/home/cimmero/gnome-shell/source/gnome-shell/src/.libs/lt-gnome-shell-real: symbol lookup error: /home/cimmero/gnome-shell/install/lib/gtk-3.0/modules/libcanberra-gtk-module.so: undefined symbol: gtk_quit_add

Per evitare di cancellare il file (non si sa mai…) l’ho rinominato:

mv /home/cimmero/gnome-shell/install/lib/gtk-3.0/modules/libcanberra-gtk-module.so /home/cimmero/gnome-shell/install/lib/gtk-3.0/modules/libcanberra-gtk-module.so_cancellato

Quindi è possibile avviare gnome-shell:

cd ~/gnome-shell/source/gnome-shell/src/
./gnome-shell –replace

Una cosa molto utile di questa procedura fornita dagli sviluppatori è che basta eseguire di nuovo il comando “jhbuild build” per scaricare/ricompilare i sorgenti modificati nei repository e provare le ultimissime novità (la policy di jhbuild è impostata su ‘updated’ nel ~/.jhbuildrc).
Un commento? E’ ancora un progetto giovane ma ha già tutta l’aria di un ottimo lavoro, i miei complimenti!

Fedora 13 con preupgrade: tentativo riuscito

Ecco di nuovo la fiammante distribuzione appena uscita e quella attualmente in uso che va benissimo. Ogni volta la stessa storia!
Che fare?
Creare una nuova partizione, installare la nuova distribuzione e reinstallare tutti i programmi che mi servono prima della migrazione della cartella utente…..dico la verità, questa volta faccio un po’ fatica.
Ma leggendo tra le note di rilascio di Fedora 13 scopro che tramite un’applicazione “preupgrade” è possibile aggiornare il sistema in uso senza problemi, addirittura direttamente da una Fedora 8 ad una 13!
Non nego di averci pensato un po’ anche perchè non essendo l’unico utente del PC casalingo non posso rischiare un fermo macchina, ahimè, per più di mezza giornata. Complice un sabato abbastanza libero mi sono deciso e ho tentato, Per chi vuol provare ecco la procedura.
Per prima cosa, sempre prima di reinstallare ma maggiormente in questo caso, è vivamente consigliato un backup di tutta la cartella home compresi i file e cartelle nascosti. Loggandoci come root è sufficiente un:
$ cp -dpR ~ /posto/al/sicuro
Poi installiamo gli ultimi aggiornamenti della distribuzione in uso:
$ yum update
Quindi basta avviare il programma da shell:
$ preupgrade
A questo punto basta rispondere alle domande banali che la semplice interfaccia grafica ci pone ed iniziare il download dei nuovi pacchetti.

Preupgrade 1

Dalle informazioni che si possono leggere nella shell il download richiede (nel mio caso) 1,7GB e altrettanto spazio disco per cui assicurarsi di avere i requisiti necessari prima di avviare tutto. Nota: in questo modo si scarica effettivamente solo il software in uso e niente di superfluo e inoltre in questo lasso di tempo è possibile continuare a lavorare con il PC; se dovesse essere spento e poi riavviato, il programma si preoccuperà di riprendere dal momento dell’interruzione.
Una volta completato il download basta riavviare la macchina.

Preupgrade 2

In pratica, al termine, preupgrade aggiunge una voce al menu di grub per cui se dovessero sorgere dei problemi in fase di avvio è possibile avviare il precedente kernel e tutto ritorna come prima (ovviamente finchè l’istallazione dei pacchetti vera e propria non è ancora iniziata).
All’avvio inizia subito la classica installazione dei pacchetti come avviene per una nuova installazione in quanto non serve specificare quale disco usare, visto che è proprio quello da cui abbiamo lanciato il programma.
Ecco fatto! Al termine ci ritroviamo nella nuova schermata di login e con il nostro solito utente e password entriamo nel sistema appena installato.
E’ possibile che non tutti i software installati abbiano il corrispettivo pacchetto della nuova distribuzione per cui alcuni pacchetti potranno rimanere non aggiornati. Per questo basta verificare quali sono con questo comando:
$ package-cleanup –orphans
Attenzione perchè tra i pacchetti elencati saranno presenti anche quelli installati “manualmente” magari da fonti diverse dai repo: prima di rimuoverli con:
$ rpm -e nomepacchetto
assicurarsi che effettivamente non servano.

Per quanto sia rischioso avviare un aggiornamento del sistema in uso (basta solo essere pronti ad una eventuale reistallazione/migrazione dati in una nuova partizione) l’uso di preupgrade è veramente comodo. In poco più di un paio d’ore (linea ADSL e prestazioni PC permettendo) ci permette di avere un sistema aggiornato senza dover menarsela a reinstallare tutta la distro ex-novo. L’unico neo, è che in questo modo non si avrà una vera nuova distribuzione “pulita” in quanto non verranno installate caratteristiche nuove non necessarie; nel mio caso ho dovuto per esempio installare manualmente il nuovo “Gnome color manager” in quanto non presente prima e non strettamente necessario. Oppure usare un nuovo file system (es: btrfs) visto che nessuna formattazione è richiesta. Personalmente sono più che soddiffatto e rimando la questione “reinstallare o aggiornare?” alla prossima release.
Dimenticavo: uso la nuova versione da qualche giorno ma già temo che gli sviluppatori abbiano fatto davvero un buon lavoro anche questa volta! 😉

Bamboo Fun & Linux? In qualche modo è possibile….

Recentemente ho acquistato una tavoletta grafica Bamboo ma sebbene sul “solito sistema operativo” funzionasse molto bene (previa installazione dei driver proprietari naturalmente) al primo tentativo con Linux ho constatato una triste realtà: non ne voleva sapere di funzionare nemmeno come mouse.
Dopo alcune ricerche tra casa madre Wacom (devo dire molto disponibili nel rispondere alle mail) e forum vari ho iniziato a seguire gli sviluppi dei driver per linux del progetto linuxwacom.
Ho scoperto che la mia tavoletta non era ancora supportata ma cominciavano a sorgere alcune patch per modificare il sorgente e compilarsi il driver “in casa”. Non sto a dilungarmi sui metodi e prove (innumerevoli) che ho fatto ma, in sintesi, viste le difficoltà con la precedente Fedora 11, ho compilato il driver per Fedora 12 con ottimi risultati (o quasi). Una particolarità di cui mi sono accorto solo ora dovendoci mettere le mani è che xorg-1.7 non necessita del file di configurazione xorg.conf ma si autoconfigura a seconda dei dispositivi collegati. Tutto ciò ha comportato circa un mese di test e nottate che indiscutibilmente avrei potuto evitare se fossi rimasto col “solito sistema operativo” dove tutto funziona al volo con i driver forniti.
La ragione per cui si fatica così tanto per costruirsi e mantenere un “mondo informatico” alternativo, merita un intero articolo (e forse non basta). Per ora ecco alcuni tra i primi sketch che ho fatto con la tavoletta.

Installare alcuni programmi utili su Fedora 12

Mi ero proposto un articolo completo ma il tempo è tiranno e se aspetto ancora, dovrò rivedere tutto per Fedora 13. Per questo intanto pubblico la prima parte, del primo quarto, del primo post sui programmi da installare (se vi servono naturalmente). Chi ben comincia…..

Plugin Flash per Firefox
Se la ricerca del plugin Flash in automatico non da risultato positivo, procedere come segue:
cliccare sul pulsante “Installazione manuale” oppure puntare il browser qui: http://get.adobe.com/it/flashplayer/
Qui selezionare il tipo di file desiderato. Io consiglio di installare il repo in modo da ottenere i successivi aggiornamenti, per cui scegliere “YUM per Linux”.
Appena terminata l’installazione, aprire un terminale e digitare questo come root:
yum -y install flash-plugin
Dopo l’installazione riavviare Firefox.


Abilitare i repository RPM fusion

Abilitando questi repo si aggiunge la possibilità di installare software aggiuntivo non incluso nei repository ufficiali Fedora per varie ragioni. I repo sono due:
free: relativo a software che risponde alle linee guida delle licenze Fedora
nonfree: relativo a software che non risponde alle linee guida delle licenze Fedora
I comandi per l’installazione di ognuno sono questi:

su -c ‘rpm -ivh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm’
su -c ‘rpm -ivh http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm’

Utilità
Questi sono i programmi che di solito aggiungo alla distribuzione appena installata; è sufficiente un “yum -y install nomeprogramma” con i privilegi di root per l’installazione:

gnome-commander : un gestore di file a due pannelli tipo konqueror.
nautilus-open-terminal : aggiunge nel menù del tasto destro di nautilus la possiblità di aprire un terminale in qualsiasi cartella visitata.
easytag : uno stupefacente gestore di tag per collezioni di mp3

(prima o poi lo continuerò……….)

Scanner Epson Perfection 2480 su Linux

In questo tutorial mostrerò come far funzionare uno scanner Epson 2480 su Linux. Io uso una Fedora 12 ma non ci dovrebbero essere differenze con altre distribuzioni in quanto il programma per scannerizzare è sempre lo stesso (xsane).
Personalmente ho provato il programma iscan prodotto da Avasys che fornisce driver Linux per apparecchiature Epson, ma a volte mi dava qualche problema per cui sono tornato ad usare xsane.
Innanzi tutto è necessario procurarsi il file del firmware dello scanner estraendolo dal file .cab presente nel CD fornito. L’estrazione può essere fatta con il programma cabextract che si trova nei repository.
ATTENZIONE!
Visto che il firmware che andremo ad usare viene caricato ogni volta nello scanner, è necessario accertarsi di usare il firmware giusto atrimenti si correrebbe il rischio di rompere il dispositivo.

Nel mio caso il file estratto si chiama Esfw41.bin e lo userò come esempio nel tutorial.

OK, a questo punto possiamo collegare la porta usb e accendere lo scanner.
Entriamo in un terminale come root e vediamo se il dispositivo è stato rilevato con:

[root@localhost sane.d]# sane-find-scanner

Tra i messaggi che escono dovrebbe essere presente una riga di questo tipo:
found USB scanner (vendor=0x04b8 [EPSON], product=0x0121 [EPSON Scanner]) at libusb:001:002
Come possiamo vedere lo scanner è stato rilevato correttamente.
Siccome xsane usa un backend per ogni tipo di scanner è necessario verificare quale è nel nostro caso con:

[root@localhost sane.d]# scanimage -L
device `snapscan:libusb:001:002′ is a EPSON EPSON Scanner flatbed scanner

Quindi il backend usato è: snapscan.
Ora è necessario modificare il file del backend per dirgli quale firmware usare. Entriamo nella cartella dei backend:

[root@localhost sane.d]# cd /etc/sane.d/

Editiamo il file:

[root@localhost sane.d]# gedit snapscan.conf &

All’inizio del file c’è una riga di questo tipo:
firmware /usr/share/sane/snapscan/your-firmwarefile.bin
Modifichiamola con:
firmware /etc/sane.d/Esfw41.bin
Salviamo il file.

Copiamo il file del firmware nella cartella che abbiamo indicato:

[root@localhost sane.d]# cp /cartella/del/mio/firmware/Esfw41.bin /etc/sane.d

A questo punto il gioco è fatto. Con il seguente comando si possono vedere tutte le opzioni supportate dal backend per il nostro scanner:

[root@localhost sane.d]# scanimage -h

Non ci resta che avviare xsane per iniziare a scannerizzare. Considerate che lo scanner ha bisogno di un tempo di riscaldamento, circa 33 secondi, che viene indicato avviando xsane da terminale.
Buon lavoro!

Gnome-shell: prime impressioni

Appena uscita la nuova Fedora 12 Beta ho preso la palla al balzo per provare, oltre alla distribuzione (la mia preferita, nemmeno a dirlo), il nuovo ambiente Gnome-shell anche se ancora in fase di test.
Appena avviata la distribuzione, ho scelto la versione live per un test veloce, è necessario soltanto aggiungere quanto necessario con “System–>Amministration–>Add/Remove Software”, ricercando il pacchetto “gnome-shell”. Verranno aggiunte alcune dipendenze e appena terminata l’installazione, non ci resta che abilitare il nuovo ambiente con “System–>Preferences–>Desktop Effects”.
Qui basta selezionare la voce “Gnome Shell” e confermare la scelta.

Il desktop che ci troviamo davanti è praticamente uguale a quello di prima con la mancanza della barra bassa e una nuova barra nera in alto in cui è presente un solo menu “Activities” a sinistra ed alcune icone a destra (rete, volume, preferenze utente).
La novità sta proprio nell’unico menù Activities che da accesso alle attività (una parola che va molto di moda ultimamente).

Gnome-shell-Fedora-Beta-2Con “Activities” aperto vengono mostrati i desktop presenti, con un effetto tipo “muraglia” e i programmi aperti su ognuno con un effetto tipo “Exposè”. Questo credo dovrebbe essere l’alternativa alle icone della barra bassa classica, praticamente sparite.
Da qui è possibile spostare le finestre dei programmi aperti da un desktop all’altro semplicemente trascinandoli.
Giocattoloso ma superfunzionale il pulsantone “+” a destra in basso, necessario per aggiungere un nuovo desktop e il corrispondente “-” nei desktop vuoti (vi lascio indovinare lo scopo).
Immediatamente disponibili premendo “Activities” ci sono i programmi aperti, i dispositivi, le cartelle principali e i documenti recenti, mentre cliccando su “more” ritroviamo ll tipico menù dei programmi completato da una descrizione per ognuno.

Gnome-shell-Fedora-Beta-1_mod

Devo dire che al primo impatto il menù completo di descrizioni non è molto pulito, soprattutto pensando a quando i programmi installati saranno ormai parecchi, Inoltre è necessario un click in più del solito per avviare un programma da menù. Di contro è stato introdotto anche qui ll campo per la ricerca (find…) che facilità questa operazione. Per aprire un programma su uno specifico desktop è anche possibile trascinare l’icona su di esso.

Gnome-shell-Fedora-Beta-4

Sebbene il mio PC non sia un superPC in fatto di prestazioni, l’impressione generale è di velocità e prontezza (non mi accorgo nemmeno di essere con una live da CD), anche la ricerca è praticamente immediata.
Personalmente la scelta del nero come sfondo non mi piace molto, avrei preferito un colore più “leggero” ma non è escluso che in futuro lo si possa personalizzare.
La sensazione che ho avuto dopo un pò è quella di “un bel vestito” al solito desktop, ma forse è proprio ciò che hanno voluto gli sviluppatori che, senza stravolgere niente, come è stato fatto in KDE pur con ottimi risultati, hanno dato una scrollatina al passato mantenendo due costanti fondamentali: semplicità ed usabilità.
Da Gnome-incallito quale sono credo che si possa fare ben presto l’abitudine ad un diverso modo di usare l’interfaccia grafica anche se ci siamo abituati nel tempo a pochi e saggi cambiamenti. A questo punto però una revisione nell’aspetto del desktop era inevitabile per poter competere in termini di “modernità” con i concorrenti (non solo KDE).