GNOME 2.28, ridammi il mio touchpad!

Ormai è quasi una settimana che utilizzo con soddisfazione, a parte dei problemini assolutamente irrilevanti di cui ho parlato, GNOME 2.28 sul mio portatile, tramite i pacchetti instabili mantenuti da JGC in un repository apposito.

Non usando mai il touchpad in questi giorni, perchè non ne avevo necessità, ho sempre usato il mouse USB, e non mi sono accorto che dopo l’aggiornamento il pad del mio laptop ha assunto un comportamento anomalo: ha smesso cioè di funzionare il click al tap.

In un primo momento, mi sono armato di bash, nano, e soprattutto di dita di scorta (:D), per risolvere il problema che credevo fosse causato da un aggiornamento di HAL o di Evdev, che magari, che so, aveva sovrascritto qualche file di configurazione di troppo, e quindi aveva inficiato sul buon funzionamento, o quantomeno sul funzionamento “alla come dico io” del mio touchpad.

Smanetta che ti rismanetta, edita che di edita, usa che ti riusa le dita di scorta, sono arrivato al dunque: numerosi reboot, e il touchpad che per quanto io bussassi forte e facessi ripetutamente toc toc, tac tac, e tic tic, non voleva saperne di clickare.

A quel punto, all’ennesimo reboot, per sbrigarmi, ho deciso di provare il tap direttamente sulla scrittona “Opzioni” presente nel mio GDM. Funzionava

Mi sono detto, “allora c’è qualcosa che non va”. Login, tutto va bene, mi ritrovo immantinente nel mio desktop, e comincio a ravanare nel dialogo delle preferenze. Scav scav scav scav… TOC! Ahi, la testa! Ho sbattuto… contro questo.

Un dialogo di preferenze? Da quando GNOME ha un dialogo di preferenze del mouse che include anche i settaggi del touchpad?

Sarà che sono troppo nerd, sarà che non sapevo della sua esistenza, fatto sta che ho ravanato nei file di configurazione di HAL per circa venti minuti prima di accorgermi del fattaccio; Adesso tutto si spiega, tutto ha un suo perchè, c’è una risposta alla vita, l’universo e tutto quanto. Non male, ottimo lavoro, però cavolo, qualcuno poteva avvisarmi eh.

E adesso tappo sul pulsante “Pubblica”.

I like the way you update it.

Da pochi giorni, JGC, il maintainer ufficiale di GNOME per quanto riguarda Arch Linux, ha istituito un repository di pacchetti precompilati contenente il mio Desktop Environment preferito aggiornato alla versione 2.27.9x.

È già da due o tre giorni che sto testando il tutto sul mio laptop con immensa soddisfazione, e sto scoprendo pian pianino tutti i cambiamenti che GNOME ha subito nel corso di questi mesi in cui mi sono crogiolato con la release 2.26: nuove interfacce di granting dei permessi, ritocchi per quanto concerne l’interfaccia, e miglioramenti diffusi in tutti i software che fanno da humus per quanto riguarda il piedone di casa Linux, sono i tratti che caratterizzano la versione che sto testando e che è destinata a trasformarsi di qui a poco nella release 2.28, l’ultima prima del grande passo che porterà a GNOME 3.

Veramente un ottimo lavoro, quello del team con un piedone nel cuore, che porta anche miglioramenti in fatto di usabilità.

L’unica nota negativa che ho da fare a questa beta appena rilasciata, è la non sufficiente leggerezza di Metacity, il quale non esita un secondo a farmi schizzare su Xorg di un bel 10% nel workflow della CPU, ma pazienza, nessuno è perfetto, e confido nel fatto che, se la cosa non verrà corretta tempestivamente, sarà riparata dai distributori nei rami “in corsa”, ossia Debian Unstable, Ubuntu Karmic (sulla quale non ho controllato), Arch Testing, Gentoo ~x86, e chi più ne ha più ne metta.

Per ora mi godo lo gnomo così come ce lo offre JGC, e fornisco uno screenshot del mio pacman.conf alle righe incriminate, per chiunque volesse inquinare la propria box Arch con software radioattivo, non maturo e che potrebbe uccidere il vostro armadillo domestico.

In fondo, un’immagine vale più di mille parole no?

Mantenere Webkit aggiornato in Ubuntu

Nel post precedente c’eravamo divertiti nel cambiare faccia al nostro Piccione viaggiatore, se ben ricordate, facendolo diventare qualcosa di molto simile a questa immagine.

Tutto ciò, ormai è risaputo per chi si è un po’ addentrato nel mondo dell’estetica da messenger, è consentito dal motore grafico Webkit, visto che le sciccherie adottate provengono in realtà da OSX, precisamente dal messenger Adium; nella precedente guida mi è stato fatto notare come su Ubuntu Jaunty ci siano problemi di compilazione del plugin che permette di utilizzare i temi di Adium, e in parecchi abbiamo visto come questo fatto dipenda dalla versione di Webkit utilizzata, che appunto in Ubuntu Jaunty è un tantinello vecchia. Occorre quindi dare una svecchiata al nostro Webkit, e possiamo mantenere aggiornato il celebre motore grafico semplicemente aggiungendo un repository alla nostra lista già molto fornita. More »

Il repository è ultimato anche per x86_64: fatevi sotto ;)

[blaster]
Server = http://ilportalinux.it/arch_repo/x86_64

Ecco a voi, arcieri sessantaquattresi italiani e non, le righe da aggiungere al vostro pacman.conf per quanto riguarda il mio repository

Enjoy it

Il repository apre, ecco a voi!

Dopo un bel po’ di scelte, e la fatica di trovare M0rF3uS per farmi mappare la home FTP, finalmente il repository che avevo promesso agli arcieri italiani, e non solo, è perfettamente funzionante e raggiungibile.

Per ora le novità sono esigue, ma una su tutte spicca: il neonato repository è infatti l’unico a fornire una versione di Gwibber funzionante perfettamente in ambiente Arch Linux. Il pacchetto è stato creato a partire da alcune modifiche apportate al PKGBUILD disponibile su AUR dal buon Uastasi, che così facendo ha permesso a me di impacchettare il software senza problemi di sorta, e a noi tutti di poter usare questo spettacolare programma anche sulla nostra distribuzione preferita. Un grazie di cuore, davvero.

Per il resto, ho soddisfatto più o meno le richieste che mi sono state fatte nei commenti al precedente post, tranne quelle del povero Emanuele che dovrà aspettare un po’: il pacchetto di Paraview è grosso trentacinque Megabyte, e non ho una connessione a fibra ottica

Per quanto riguarda gli altri software di fluidodinamica computazionale, OpenCascade ci mette un casino di tempo a compilare, e in questo periodo non ho proprio tempo di dedicare la CPU a quel mostro, e Gmsh richiede OpenCascade. Per MeshLab invece, sto procedendo pian pianino verso la creazione di un PKGBUILD, anche se procedo a rilento per via del fatto che devo impacchettare altre cose.

Beh, non resta che iniziare a goderci insieme i frutti di questo lavoro; basta aggiungere al proprio pacman.conf le seguenti righe:

[blaster]
Server = http://ilportalinux.it/arch_repo/i686

Refreshare i repository con pacman -Sy, e magari provare ad installare qualche pacchetto

L’unico difetto per ora, è che non ho una Arch64 sotto mano, quindi chi volesse offrirsi di ricompilare tutto per processori a 64 bit, non deve fare altro che dirmelo.

Repository nascente per Arch: richieste particolari?

Visto che poco tempo fa è nata da me e M0rF3uS, e cercavamo giustappunto idee su quali pacchetti includere nel repository, ho pensato bene di chiedere ai lettori delle mie pagine cosa ne pensassero e se avessero consigli sui pacchetti da includere.

Ovviamente, la richiesta è condivisa con tutti gli arcieri italiani.

Forza, mettiamo su una buona risorsa a livello italiano e, perchè no, mondiale, per estendere il parco di precompilati!

ArchLinux Testing, [intel] e Xorg 1.6.0

Ok, oggi ufficialmente i nuovi pacchetti con driver, input e quant’altro, compreso il nuovo server X 1.6.0, sono entrati nel repository Testing.

Suggerisco quindi di abbandonare il mio repository e abilitare tranquillamente Testing, per poter avere dei driver aggiornati assieme a Mesa e varie librerie.

Abilitato Testing, basta un

pacman -Sf xf86-video-intel intel-dri libdrm mesa libgl xorg-server

da root, dopo aver disabilitato il mio repository per abbandonarlo definitivamente. Ovviamente chi non utilizza alcuni dei pacchetti sopra citati non esiti a modificare il comando.

Stessa procedura per chi usa il mio repository senza Testing abilitato. Conviene assolutamente che venga eseguita quando Xorg 1.6.0 e gli altri pacchetti approderanno in Extra.

Xorg-Server 1.6.0 in ArchLinux Testing

Ebbene, dopo un bel po’ di tempo dall’ultima release stabile, entra a far parte di ArchLinux Testing la versione 1.6.0 del blasonato server grafico.

La cosa importante da notificare è che i driver che io impacchetto per il mio personale repository a quanto pare necessitano di essere ricompilati per funzionare sotto tale server.

Per questo motivo è sconsigliato l’aggiornamento a tutti coloro che utilizzano i pacchetti forniti da me, finchè il repository non verrà da me aggiornato.

Con questo passo e chiudo.

Ad maiora

Repository: aggiornato LibDRM e xf86-video-intel

Post di servizio, per avvisare la seppur piccola utenza del mio repository per MESA e schede video intel, che i pacchetti di LibDRM e XF86-Video-Intel sono stati aggiornati alle verisioni più recenti: 2.4.5 per LibDRM e 2.6.2 per XF86-Video-Intel.

Malfunzionamenti da segnalare nessuno, almeno da parte mia; come al solito è gradito il feedback.

ArchLinux: repository dedicato a MESA e driver Intel by Bl@ster

Da poco, mi sono accorto che la versione di MESA nei repository ufficiali ArchLinux era la 7.2, mentre era da qualche tempo uscita la 7.3.

E con l’uscita del nuovo MESA, anche intel-dri e altri pacchetti hanno subito di conseguenza cambiamenti spaventosi, nel mio caso migliori. Quindi, senza indugiare oltre, ho impacchettato tutto ciò che mi pareva essere oltremodo vecchio, e l’ho messo sul mio spazietto online (Grazie a Luca!).

Potete quindi aggiungere già da adesso in cima al vostro pacman.conf il mio repository dedicato a tutti quei pacchetti che vengono lasciati, nei repository ufficiali, ad una versione precedente. Questo per quanto riguarda, ovviamente, le schede video Intel e MESA.

[intel]
Server = http://blaster.tuttoeniente.net/arch/intel

Sembra quasi scontato dire che se avete richieste, o volete riportare qualche baco o imperfezione, siete liberi di farlo, anzi, è apprezzato che lo facciate.

Sappiate però che non sono un mostro di programmatore, e nemmeno un grande patchatore