mercoledì 21 dicembre 2011

Integrare le applicazioni GTK+ in KDE

Le applicazioni scritte con il toolkit GTK+ (come praticamente tutte le applicazioni dell'ambiente desktop GNOME) non sono nativamente ben integrate nell'ambiente desktop KDE (che invece si basa sul toolkit Qt).

Il toolkit GTK+ permette di impostare un tema per tutte le applicazioni che lo utilizzano, quindi per migliorare l'aspetto di queste applicazioni all'interno di KDE abbiamo bisogno di un tema che assomigli il più possibile al tema in uso su KDE. Esistono diversi temi GTK+ che ben si integrano con le applicazioni Qt, come QtCurve, però in particolare segnalo l'esistenza del tema Oxygen-gtk che è una traduzione in GTK+ del tema predefinito di KDE, cioè Oxygen. Non è scopo di questa guida spiegare come si installano in generale i temi GTK+, vedremo solo come si installa Oxygen-gtk su Debian e sistemi derivati e come fare per utilizzarlo. Sugli altri sistemi operativi (Fedora, openSUSE, Gentoo, Arch Linux, eccetera) potranno cambiare i nomi dei pacchetti da installare e il gestore pacchetti da usare, ma le operazioni da eseguire saranno grosso modo le stesse.

È possibile installare Oxygen-gtk scaricandolo da qui e seguendo le istruzioni riportate nella pagina oppure, su Debian e derivate, installando il pacchetto gtk2-engines-oxygen tramite il gestore pacchetti Synaptic o sul terminale con il comando
sudo apt-get install gtk2-engines-oxygen
Ora dobbiamo solo impostare questo tema come quello utilizzato dalle applicazioni GTK+. Esiste una procedura manuale ben descritta in questa guida (in inglese) del wiki di Arch Linux, ma esiste anche una procedura automatica basata sull'utilizzo di un'apposita interfaccia grafica. Ci sono diversi semplici programmi che permettono di selezionare il tema GTK+ fra i quali gtk-chtheme e lxappearance, ma dal momento che stiamo parlando dell'ambiente desktop KDE suggerisco di utilizzare il selettore dei temi GTK che fa parte degli strumenti di sistema di KDE. Per installarlo su Debian e derivate bisogna installare il pacchetto kde-config-gtk-style con Synaptic oppure via terminale con il comando
sudo apt-get install kde-config-gtk-style
Si può adesso selezionare il tema in Impostazioni di sistema, scegliendo Aspetto delle applicazioni e impostando nella scheda Aspetto GTK lo stile oxygen-gtk.
Manca solo un'ultima operazione prima di finire. Scegliendo lo stile con il programma Impostazioni di sistema abbiamo creato un file nascosto il cui percorso è ~/.gtkrc-2.0-kde (ricordo che la tilde ~ è un'abbreviazione del percorso della home dell'utente corrente), ma per rendere efficace questa impostazione il file deve chiamarsi ~/.gtkrc-2.0 quindi dobbiamo rinominare il file ~/.gtkrc-2.0-kde in ~/.gtkrc-2.0, oppure copiare ~/.gtkrc-2.0-kde e incollarlo con il nuovo nome ~/.gtkrc-2.0 oppure creare un link simbolico ~/.gtkrc-2.0 che punta a ~/.gtkrc-2.0-kde. Per visualizzare i file nascosti in Dolphin bisogna premere la scorciatoia da tastiera ALT + . oppure queste operazioni possono essere eseguite da terminale rispettivamente con i seguenti comandi (basta eseguirne solo uno, quello che si preferisce!):
mv ~/.gtkrc-2.0-kde ~/.gtkrc-2.0 # per rinominare il file
cp ~/.gtkrc-2.0-kde ~/.gtkrc-2.0 # per copiare il file
ln -s ~/.gtkrc-2.0-kde ~/.gtkrc-2.0 # per creare il link simbolico
Adesso tutte le applicazioni GTK che verranno aperte risulteranno finalmente ben integrate con le applicazioni Qt di KDE.

Un'ultima osservazione: l'impostazione del tema GTK viene letta solo dai programmi eseguiti dall'utente nella cui cartella home si trova il file .gtkrc-2.0, ciò permette agli utenti di uno stesso sistema di usare diversi temi. Questo vale anche per l'utente "root", pertanto se si vuole che anche le applicazioni eseguite come utente "root" utilizzino il tema scelto bisogna inserire nella home dell'utente "root" il file .gtkrc-2.0. Per fare questo possiamo copiare il file nella home di "root" oppure creare all'interno di questa un link simbolico al nostro file .gtkrc-2.0 in modo che tutte le modifiche apportate al nostro file .gtkrc-2.0 valgano automaticamente anche per l'utente "root" senza dover modificare ulteriormente suoi file. Da terminale queste due operazioni possono essere eseguite con i comandi (di nuovo, va usato solo uno di questi comandi, quello che si preferisce)
sudo cp ~/.gtkrc-2.0 ~root/.gtkrc-2.0 # per copiare il file
sudo ln -s ~/.gtkrc-2.0 ~root/.gtkrc-2.0 # per creare il link simbolico



Aggiornamento: il tema Oxygen-gtk supporta anche la versione 3 del toolkit GTK+, nei repository di Debian e Ubuntu è presente il pacchetto gtk3-engines-oxygen. Per installarlo da terminale:
sudo apt-get install gtk3-engines-oxygen
La modalità di configurazione del tema per GTK3 però è diversa rispetto a quella per GTK2. Non mi risulta che esistano strumenti per selezionare automaticamente il tema, tuttavia bisogna solo creare un file chiamato settings.ini nella cartella ~/.config/gtk-3.0 (ricordo che la tilde ~ è un'abbreviazione per il percorso della home dell'utente corrente e che i file e cartelle i cui nomi iniziano con un punto non sono normalmente visibili, premere ALT + . in Dolphin per visualizzarli), cartella da creare se non già esistente. All'interno di questo file è sufficiente scrivere
[Settings] 
gtk-theme-name=oxygen-gtk
Dopo aver salvato il file le modifiche dovrebbero avere effetto immediatamente su tutte le applicazioni grafiche basate sul toolkit GTK3. Se si vuole fare tutto da terminale si possono dare i seguenti comandi
mkdir -p ~/.config/gtk-3.0
echo -e '[Settings]\ngtk-theme-name=oxygen-gtk' > ~/.config/gtk-3.0/settings.ini~/.config/gtk-3.0/settings.ini
Il primo comando crea la cartella se non esiste già, il secondo crea il file con il contenuto sopra indicato.

Anche i temi delle applicazioni GTK3 possono essere diversi da utente a utente. Come detto anche per le applicazioni GTK, possiamo automaticamente dare all'utente root le nostre stesse impostazioni eseguendo da terminale uno dei due seguenti comandi, a scelta
sudo cp ~/.gtkrc-3.0 ~root/.gtkrc-3.0 # per copiare il file
sudo ln -s ~/.gtkrc-3.0 ~root/.gtkrc-3.0 # per creare il link simbolico

giovedì 11 agosto 2011

Compilare moduli del kernel con DKMS

Il Dynamic Kernel Module Support (DKMS) è un sistema che permette di generare moduli per il kernel Linux i quali non sono presenti nel sorgente del kernel stesso. Quando viene installata una nuova versione del kernel Linux, normalmente è necessario ricompilare questi moduli. Nei sistemi Debian e derivati (e probabilmente anche in altre distribuzioni con kernel Linux), questa operazione viene svolta automaticamente eseguendo lo script /usr/lib/dkms/dkms_autoinstaller. A volte, però, si potrebbe voler ricompilare manualmente un modulo, oppure compilarlo per una versione del kernel diversa da quella per cui esiste già. La sintassi da usare per ricompilare un modulo chiamato <modulo> è la seguente
sudo dkms build -m <modulo> -v <versione_modulo> -k <versione_kernel>
sudo dkms install -m <modulo> -v <versione_modulo> -k <versione_kernel>
sudo dkms status
Il primo comando serve per compilare il modulo, nella versione <versione_modulo> e per il kernel <versione_kernel>, il secondo comando serve per installare il modulo compilato (prima di procedere con questo comando assicurarsi che la compilazione sia andata a buon fine. La buona riuscita o meno della compilazione viene segnalata dai messaggi di output del comando dkms build) e l'ultimo serve per verificare lo stato dei moduli gestiti da DKMS, per controllare che i moduli desiderati siano stati effettivamente installati. Per conoscere la versione del kernel attualmente in uso si può dare nel terminale il comando uname -r.

Quando si installa una nuova versione dei driver proprietari della scheda video (farò l'esempio con una scheda Nvidia), viene compilato solo il modulo per il kernel attualmente in uso (oltre ai kernel successivamente installati, come abbiamo già detto prima). Si potrebbe, però, voler compilare il modulo anche per una versione del kernel diversa da quella in uso (come può essere una versione precedente). Ammettiamo quindi per esempio che il modulo che si voglia ricompilare è il driver Nvidia, chiamato nvidia, che la sua versione è la 280.13 e che il kernel per il quale si vuole ricompilare il modulo è il 3.0.0-1-686-pae. Dunque dovremo dare i seguenti comandi per compilare e installare il modulo:
sudo dkms build -m nvidia -v 280.13 -k 3.0.0-1-686-pae
sudo dkms install -m nvidia -v 280.13 -k 3.0.0-1-686-pae
Alla fine potremo usare il comando dkms status per controllare lo stato dei moduli così installati. L'output sarà qualcosa di questo tipo
nvidia, 280.13, 2.6.38-2-686, i686: installed
nvidia, 280.13, 2.6.39-2-686-pae, i686: installed
nvidia, 280.13, 3.0.0-1-686-pae, i686: installed
Naturalmente consiglio di consultare il manuale di DKMS (man dkms) per avere maggiori informazioni sul programma e le sue opzioni.

Invece di usare dkms build e dkms install, è possibile utilizzare il comando dkms autoinstall che installa, per una specifica versione del kernel, tutti i moduli che sono già installati per altre versioni del kernel diverse da quella indicata. La sintassi è
sudo dkms autoinstall --kernelver <versione_kernel>
Si può anche eseguire direttamente lo script dkms_autoinstaller citato all'inizio (il breve script dkms_autoinstaller richiama a sua volta dkms autoinstall al suo interno). La sintassi è
/usr/lib/dkms/dkms_autoinstaller start
se si vogliono compilare i moduli per il kernel attualmente in uso oppure
/usr/lib/dkms/dkms_autoinstaller start <versione_kernel>
se si vuole indicare una particolare versione del kernel.

I comandi sopra spiegati sono validi solo se il modulo è già predisposto per la compilazione con DKMS. Per aggiungere il supporto a DKMS a dei moduli di cui si possiede il codice sorgente si può vedere qui.

I comandi di questo post sono stati presi dal seguente messaggio dell'utente bugsbunny sul forum forums.debian.net: http://forums.debian.net/viewtopic.php?f=6&t=66973#p382913.

domenica 26 giugno 2011

Conflitto fra i moduli delle schede audio

Sul mio vecchio muletto ho due schede audio, una integrata e una esterna. Questo è la parte dell'output del comando lspci -v che riguarda le mie due schede audio
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
        Subsystem: C-Media Electronics Inc CMI9739(A) on ECS K7SOM+ motherboard
        Flags: bus master, medium devsel, latency 64, IRQ 11
        I/O ports at d800 [size=256]
        I/O ports at d400 [size=64]
        Capabilities: <access denied>
        Kernel modules: snd-intel8x0

00:11.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08)
        Subsystem: Creative Labs SBLive! 5.1 Model SB0100
        Flags: bus master, medium devsel, latency 64, IRQ 11
        I/O ports at d000 [size=32]
        Capabilities: <access denied>
        Kernel driver in use: EMU10K1_Audigy
        Kernel modules: snd-emu10k1
La scheda integrata è la prima (e segue lo standard AC'97), la seconda è la scheda esterna. Le casse audio sono collegate alla scheda esterna e su Windows (mi duole ammetterlo) l'audio funziona senza problemi, mentre su Ubuntu non sentivo nulla fino a qualche minuto fa (in realtà l'audio funzionava prima di aggiornare Ubuntu alla versione 9.10 Karmic Koala). Ho impiegato più di un anno e mezzo per capire quale fosse il problema ma l'importante è arrivarci (e da solo!): facevano conflitto i driver (o "moduli") delle due schede (anche se non so perché con le precedenti versioni di Ubuntu questo problema non si presentasse). I nomi dei moduli del kernel utilizzati dalle due schede possono essere letti nell'output del comando lspci -v: snd-intel8x0 per la scheda integrata (cioè quella che non uso) e snd-emu10k1 per la scheda esterna.

Per mettere in blacklist un modulo del kernel chiamato modulo bisogna mettere in un file con estensione .conf della cartella /etc/modprobe.d la riga
blacklist modulo
Dunque per far tornare magicamente l'audio sul mio computer ho dato il seguente comando da terminale
echo "blacklist snd_intel8x0" | sudo tee /etc/modprobe.d/blacklist-audio.conf
È possibile aggiungere un commento, per ricordarsi perché si è aggiunto un modulo alla blacklist, facendo iniziare le righe di commento con #. Per esempio ho modificato il file appena creato (con i diritti di amministratore perché si trova sotto /etc) aggiungendo il seguente commento
# Metto il modulo della scheda audio integrata nella blacklist per
# evitare che entri in conflitto con quello della scheda esterna
blacklist snd_intel8x0

domenica 24 aprile 2011

Schermo nero al ritorno dalla sospensione

Dopo aver aggiornato il kernel Linux alla versione 2.6.38 (ma non sono sicuro che sia questa particolare versione del kernel la causa del problema) al ritorno dalla sospensione trovo lo schermo nero senza la possibilità di fare nulla. In realtà basta premere ALT + CTRL + F7 (o altro tasto funzione associato alla console in cui è avviato il server grafico X.org) per far comparire la la schermata per l'inserimento della password e tornare a utilizzare il proprio computer. Nel file di log /var/log/pm-suspend.log in corrispondenza del ritorno dalla sospensione compare qualcosa del tipo:
/usr/lib/pm-utils/sleep.d/99video suspend suspend: success.
Sun Apr 24 17:17:00 CEST 2011: performing suspend
Sun Apr 24 17:18:39 CEST 2011: Awake.
Sun Apr 24 17:18:39 CEST 2011: Running hooks for resume
Running hook /usr/lib/pm-utils/sleep.d/99video resume suspend:
Couldn't get a file descriptor referring to the console
VT_DISALLOCATE: Device or resource busy
deallocvt: could not deallocate console 63
Come segnalato qui per risolvere il problema dovrebbe essere sufficiente creare il file /etc/pm/config.d/10no-vt-switch contenente semplicemente
ADD_PARAMETERS=" --quirk-no-chvt "
però non ho provato personalmente questa soluzione. Il problema comunque potrebbe essere molto legato al particolare hardware del computer usato. Quindi controllate se i vostri componenti sono gli stessi di quelli riportati sul Wiki di Debian.

Emacs: effettuare il controllo della sintassi di documenti LaTeX

Nel post Opzioni utili per comporre documenti LaTeX in GNU Emacs + AUCTeX illustrai le principali opzioni di Emacs che trovo particolarmente utili per scrivere documenti LaTeX. Ora voglio mostrare l'impostazione di uno strumento esterno a AUCTeX ma che ritengo molto utile.

Il pacchetto Flymake, presente di default nelle ultime versioni di GNU Emacs, permette di effettuare un controllo della sintassi al volo, cioè durante la scrittura di un codice. Quindi per trovare un errore formale all'interno di questo non sarà necessario avviare manualmente la compilazione ma sarà Emacs stesso ad avvisare della loro presenza. Per fare questo Flymake si appoggia a programmi esterni di controllo della sintassi. Per quanto riguarda LaTeX esistono almeno un paio di programmi specifici: Lacheck e ChkTeX. Il primo non è più sviluppato dal 1997 e ha difficoltà con macro molto elaborate, quindi molto probabilmente non vorrete utilizzarlo (sebbene sia lo strumento predefinito da Emacs per effettuare l'analisi sintattica, non al volo, che si avvia con C-c C-c Check RET. È possibile cambiare questa impostazione modificando la variabile TeX-command-list come visto prima), il secondo progetto è un po' più attivo. Inoltre per effettuare un controllo della sintassi è possibile anche utilizzare i compilatori stessi latex, pdflatex, ecc., utilizzati con delle opportune opzioni di compilazione che vedremo più avanti.

Volendo usare ChkTex bisogna inserire nel proprio file di inizializzazione ~/.emacs il seguente codice:
(require 'flymake)
(defun flymake-get-tex-args (file-name)
  (list "chktex" (list "-q" "-v0" file-name)))
(add-hook 'LaTeX-mode-hook 'flymake-mode) 
Analizziamo nel dettaglio queste istruzioni: la riga (require 'flymake) dice semplicemente a Emacs di caricare il pacchetto flymake; le due successive specificano il programma esterno da usare (nel caso specifico chktex) e i relativi argomenti da passare, nel nostro caso -q -v0 seguiti dal nome del file che si sta modificando contenuto nella variabile file-name. Per capire cosa fanno le varie opzioni consultare il manuale. Infine l'ultima fa in modo che ogni volta che si apre un documento con la major mode LaTeX-mode venga attivata la minor mode flymake-mode. Se non si vuole aggiungere questa ultima funzione sarà necessario attivare manualmente la modalità con M-x flymake-mode.

Penso sia ora chiaro come bisogna modificare il codice precedente per appoggiarsi a uno strumento diverso da ChkTex. Bisogna sostituire a chktex il nome del programma desiderato e inserire al posto di "-q" "-v0" l'eventuale elenco di opzioni volute. Per esempio, volendo usare Lacheck, senza alcuna opzione passata da linea di comando, dovremo inserire
(require 'flymake)
(defun flymake-get-tex-args (file-name)
  (list "lacheck" (list file-name)))
(add-hook 'LaTeX-mode-hook 'flymake-mode) 

Come detto, è possibile anche utilizzare il compilatore stesso per effettuare un controllo della sintassi. Infatti quando compiliamo un documento il compilatore ci avvisa della presenza di errori. Tuttavia normalmente l'esecuzione della compilazione viene interrotta al punto in cui viene incontrato un errore, mentre noi vogliamo che tutto il codice sorgente venga analizzato affinché siano riportati tutti gli errori presenti e ciò può essere realizzato passando a pdflatex l'opzione -interaction=nonstopmode. Altre opzioni utili nel nostro caso sono -draftmode, che impedisce la creazione del file di output in PDF velocizzando così l'esecuzione del controllo, e -file-line-error, per fare in modo che Flymake possa effettuare correttamente il parsing dell'output di pdflatex. Dunque per utilizzare pdflatex come strumento di controllo della sintassi dovremo inserire il seguente codice nel nostro file di inizializzazione:
(require 'flymake)
(defun flymake-get-tex-args (file-name)
  (list "pdflatex"
        (list "-file-line-error" "-draftmode" "-interaction=nonstopmode" file-name)))
(add-hook 'LaTeX-mode-hook 'flymake-mode) 
Ricordo sempre che si potrebbe non voler inserire l'ultima riga preferendo attivare manualmente la modalità flymake-mode solo nei documenti in cui si desidera effettivamente svolgere l'analisi sintattica.

Una volta attivata la modalità flymake-mode gli errori saranno evidenziati in rosso e passando sul testo incriminato con il mouse oppure usando il comando M-x flymake-display-err-menu-for-current-line verrà mostrata la spiegazione dell'errore segnalato.

Devo evidenziare che pdflatex è piuttosto dispendioso dal punto di vista delle risorse di sistema e inoltre molto lento per i documenti grandi. Facendo delle prove su un documento di circa 200 pagine nel documento di output ChkTex e Lacheck hanno impiegato meno di mezzo secondo per concludere l'analisi dell'intero codice sorgente, contro gli oltre 20 secondi di pdflatex. D'altra parte il programma più affidabile è il compilatore stesso, infatti è l'unico dei tre programmi qui discussi in grado di riconoscere i comandi o pacchetti non esistenti. Se si preferisce la velocità a discapito della precisione allora lo strumento ideale è ChkTex, se invece si vuole un controllo più preciso e mirato allora pdflatex fa al caso vostro (in particolare nei documenti piccoli).

Trovate maggiori informazioni su Flymake sul sito Emacs Wiki alle pagine Fly Make e Flymake Tex (da cui questo post prende ispirazione), oppure nel manuale consultabile dentro Emacs con C-h i d m Flymake RET.

lunedì 4 aprile 2011

Aggiungere "Monta archivi" in Debian

Chi ha usato, almeno provato o visto Ubuntu, dalla versione 8.10 in poi, probabilmente avrà notato che facendo clic con il tasto destro sull'icona di un'immagine .iso è possibile scegliere l'opzione «Apri con Monta archivi». Questa opzione permette di montare rapidamente e per via grafica l'immagine che altrimenti potrebbe essere montata su un terminale con un comando di questo tipo
mount -o loop -t iso9660 /percorso/della/immagine.iso /punto/di/mount
in cui bisognerà naturalmente sostituire a /percorso/della/immagine.iso il percorso dell'immagine che si vuole montare e a /punto/di/mount il percorso del punto di mount scelto e precedentemente creato.

È possibile aggiungere l'opzione «Apri con Monta archivi» anche in Debian (dovrebbe funzionare da Lenny in poi, personalmente ho provato su Wheezy testing) semplicemente copiando il lanciatore utilizzato in Ubuntu per aggiungere quell'opzione. Prima di fare ciò bisogna installare, se non già presente, il pacchetto gvfs-backends:
apt-get install gvfs-backends
A questo punto è possibile scaricare il lanciatore dall'indirizzo http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/nautilus/natty/download/head:/mountarchive.desktop-20100222031218-t6ar3c8jxy685cre-2783/mount-archive.desktop (come ottenere questo indirizzo, che potrebbe cambiare in futuro: andare in https://code.launchpad.net/ubuntu/+source/nautilus, selezionare il ramo principale lp:ubuntu/nautilus → Browse the code, reperire il file debian/mount-archive.desktop) e metterlo nella cartella ~/.local/share/applications se si vuole che sia disponibile solo per il proprio utente, altrimenti in /usr/share/applications/ affinché possa essere usato da tutti gli utenti del sistema. Da terminale può essere scaricato con il comando
wget -P ~/.local/share/applications http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/nautilus/natty/download/head:/mountarchive.desktop-20100222031218-t6ar3c8jxy685cre-2783/mount-archive.desktop
nel primo caso, per il secondo:
wget -P /usr/share/applications http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/nautilus/natty/download/head:/mountarchive.desktop-20100222031218-t6ar3c8jxy685cre-2783/mount-archive.desktop
usando i diritti di root per poter scrivere sotto /usr.


È possibile aggiungere nel lanciatore, utilizzando un qualsiasi editor di testo, la riga
Name[it_IT]=Monta archivi
in modo che il nome dell'opzione sia in italiano se il sistema è localizzato in italiano.

Ho detto che questo sistema funziona su Debian, in realtà dovrebbe funzionare su qualsiasi sistema GNU/Linux che abbia il programma gvfsd-archive.

sabato 26 febbraio 2011

Compilare GNU Octave 3.4.0

Lo scorso 8 febbraio è stata rilasciata la versione 3.4.0 di GNU Octave, sostituto libero di MATLAB. Trovate le novità di questa versione qui.

In questo post spiegherò come compilare questa versione di GNU Octave. Qualche mese fa avevamo visto come compilare la versione 3.2.2. Non sarà molto diverso compilare la 3.4.0, anzi, personalmente ho incontrato molti meno problemi nel compilare la 3.4.0 rispetto alla 3.2.2. La guida è stata sperimentata su Ubuntu 10.10, non dovrebbero esserci praticamente differenze per compilare GNU Octave su Debian Sid. Per le altre distribuzioni GNU/Linux le uniche cose differenti saranno probabilmente i comandi da usare per richiamare il gestore pacchetti utilizzato.

Per prima cosa installiamo il compilatore installando il metapacchetto build-essential. Questo può essere installato da Synaptic, oppure da terminale con il comando:
sudo apt-get install build-essential
Il metapacchetto build-essential installa i compilatori se non già presenti, se sono già installati... non fa praticamente nulla. In questo modo comunque ci assicuriamo di averli installati. Dopo di ciò installiamo le dipendenze, ovvero le librerie necessarie per la compilazione di GNU Octave. Possiamo fare ciò molto velocemente da terminale con il comando:
sudo apt-get build-dep octave3.2
Questo comando installerà le dipendenze necessarie per compilare il ramo 3.2 di GNU Octave, ma queste sono praticamente identiche a quelle del ramo 3.4. Manca solo una libreria da installare. Non impedisce la compilazione, però potrebbe essere utile in alcuni casi. Si chiama bison e può essere installata come al solito da Synaptic oppure da terminale con il comando
sudo apt-get install bison
Scarichiamo ora il codice sorgente di GNU OCtave: http://www.gnu.org/software/octave/download.html. La versione 3.4.0 può essere scaricata da terminale con il comando
wget ftp://ftp.gnu.org/gnu/octave/octave-3.4.0.tar.bz2
Scompattiamo l'archivio. Lo si può fare per via grafica oppure da terminale con il comando
tar xjvf octave-3.4.0.tar.bz2
Entriamo con il terminale nella cartella principale del codice sorgente di GNU Octave:
cdd octave-3.4.0/
Leggiamo i file README e INSTALL che spiegano come si compila il programma. Per prima cosa dobbiamo configurare il programma usando lo script configure. Potete vedere l'elenco delle opzioni di configurazione possibili richiamando lo script con l'opzione --help:
./configure --help
Possiamo ora configurare GNU Octave:
./configure
Se lo ritenete necessario potete, naturalmente, aggiungere le opzioni che preferite. Se tutto è andato a buon fine dovreste leggere alla fine dell'output di ./configure qualcosa di questo tipo:
Octave is now configured for i686-pc-linux-gnu

  Source directory:            .
  Installation prefix:         /usr/local
  C compiler:                  gcc  -mieee-fp  -Wall -W -Wshadow -Wformat -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -pthread
  C++ compiler:                g++  -mieee-fp  -I/usr/include/freetype2    -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2
  Fortran compiler:            gfortran -O -mieee-fp
  Fortran libraries:            -L/usr/lib/gcc/i686-linux-gnu/4.4.5 -L/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i686-linux-gnu/4.4.5/../../.. -L/usr/lib/i686-linux-gnu -lgfortranbegin -lgfortran -lm
  Lex libraries:               
  LIBS:                        -lm  

  AMD CPPFLAGS:                
  AMD LDFLAGS:                 
  AMD libraries:               -lamd
  BLAS libraries:              -lblas
  CAMD CPPFLAGS:               
  CAMD LDFLAGS:                
  CAMD libraries:              -lcamd
  CARBON libraries:            
  CCOLAMD CPPFLAGS:            
  CCOLAMD LDFLAGS:             
  CCOLAMD libraries:           -lccolamd
  CHOLMOD CPPFLAGS:            
  CHOLMOD LDFLAGS:             
  CHOLMOD libraries:           -lcholmod
  COLAMD CPPFLAGS:             
  COLAMD LDFLAGS:              
  COLAMD libraries:            -lcolamd
  CURL CPPFLAGS:               
  CURL LDFLAGS:                
  CURL libraries:              -lcurl
  CXSPARSE CPPFLAGS:           
  CXSPARSE LDFLAGS:            
  CXSPARSE libraries:          -lcxsparse
  DL libraries:                -ldl
  FFTW3 CPPFLAGS:              
  FFTW3 LDFLAGS:               
  FFTW3 libraries:             -lfftw3
  FFTW3F CPPFLAGS:             
  FFTW3F LDFLAGS:              
  FFTW3F libraries:            -lfftw3f
  fontconfig CFLAGS:            
  fontconfig LIBS:             -lfontconfig  
  FT2_CFLAGS:                  -I/usr/include/freetype2
  FT2_LIBS:                    -lfreetype -lz
  GLPK CPPFLAGS:               
  GLPK LDFLAGS:                
  GLPK libraries:              -lglpk
  graphics CFLAGS:             -g -O2 -D_THREAD_SAFE -D_REENTRANT
  graphics LIBS:               -Wl,-Bsymbolic-functions -lfltk_gl -lfltk
  Magick++ CPPFLAGS:           -I/usr/include/GraphicsMagick  
  Magick++ LDFLAGS:             
  Magick++ libraries:          -lGraphicsMagick++ -lGraphicsMagick  
  HDF5 CPPFLAGS:               
  HDF5 LDFLAGS:                
  HDF5 libraries:              -lhdf5
  LAPACK libraries:            -llapack
  OPENGL libraries:            -lfontconfig   -lGL -lGLU
  PTHREAD flags:               -pthread
  PTHREAD libraries:           
  QHULL CPPFLAGS:              
  QHULL LDFLAGS:               
  QHULL libraries:             -lqhull
  QRUPDATE libraries:          -lqrupdate
  READLINE libraries:          -lreadline
  REGEX libraries:             -L/usr/lib -lpcre
  TERM libraries:              -lncurses
  UMFPACK libraries:           -lumfpack
  X11 include flags:           
  X11 libraries:               -lX11
  Z CPPFLAGS:                  
  Z LDFLAGS:                   
  Z libraries:                 -lz

  Default pager:               less
  gnuplot:                     gnuplot

  Do internal array bounds checking:  false
  Build static libraries:             false
  Build shared libraries:             true
  Dynamic Linking:                    true (dlopen)
  Include support for GNU readline:   true
  64-bit array dims and indexing:     false
Se non avessimo installato bison avremmo inoltre letto un avviso di questo tipo:
configure: WARNING: I didn't find bison, but it's only a problem if you need to reconstruct parse.cc
configure: WARNING: OpenGL libs (GL and GLU) not found. Native graphics will be disabled.
configure: WARNING: 
configure: WARNING: I didn't find the necessary libraries to compile native
configure: WARNING: graphics.  It isn't necessary to have native graphics,
configure: WARNING: but you will need to have gnuplot installed or you won't
configure: WARNING: be able to use any of Octave's plotting commands
configure: WARNING: 
configure: 
configure: NOTE: libraries may be skipped if a library is not found OR
configure: NOTE: if the library on your system is missing required features.
Questo è il messaggio che ho ottenuto io dopo la prima configurazione (non avevo però ancora installato bison). Come potete vedere mi è stata segnalata l'assenza delle librerie OpenGL. Ho risolto questo "problema" (non è un vero e proprio problema perché si tratta solo di un avviso, non è un errore) installando i pacchetti libgl1-mesa-dev e libglu1-mesa-dev:
sudo apt-get install libgl1-mesa-dev libglu1-mesa-dev
Normalmente questo problema non dovrebbe verificarsi perché questi pacchetti dovrebbero essere installati usando apt-get build-dep octave3.2, non so bene per quale motivo a me sono stati rimossi.

Dopo aver finalmente configurato GNU Octave possiamo compilarlo con il comando
make
Per rendere più veloce la compilazione, chi ha un processore multicore può passare a make l'opzione -j n, dove n è il numero di core del processore (o meglio di job simultanei che può gestire, però per semplificare il discorso parliamo di core). Quindi chi, per esempio, ha un processore con quattro core potrà usare per compilare GNU Octave il comando
make -j 4
Se la compilazione va a buon fine (a seconda della potenza di calcolo del proprio computer questa operazione può richiedere da poche decine di minuti a qualche ora) alla fine dell'operazione leggerete sul terminale un messaggio di questo tipo:
Octave successfully built.  Now choose from the following:

   ./run-octave    - to run in place to test before installing
   make check      - to run the tests
   make install    - to install (PREFIX=/usr/local)

make[2]: uscita dalla directory "/[...]/octave-3.4.0"
make[1]: uscita dalla directory "/[...]/octave-3.4.0"
Come potete vedere, prima di installare Octave potete avviarlo per verificare se funzioni con il comando
./run-octave
Infine possiamo installarlo con il comando
sudo make install
Se invece vogliamo crare un pacchetto .deb per rendere più semplice la successiva installazione o rimozione possiamo usare checkinstall:
sudo checkinstall

domenica 20 febbraio 2011

Compilare QtiPlot 0.9.8.4

NOTA: Renato Rivoira, che ringrazio, ha curato la traduzione in italiano di QtiPlot e del suo manuale. Nei commenti a questo post chiede, a chi sia in grado di farlo, di aiutarlo a revisionare le sue traduzioni. Potete contattarlo mandandogli una mail all'indirizzo renatoriv AT ​libero PUNTO it.

Il 18 febbraio 2011 è stata rilasciata la versione finale di QtiPlot 0.9.8.4, un programma per l'analisi dei dati, equivalente libero di Origin. Questa versione porta con sé numerose novità che potete leggere qui.

QtiPlot è un programma un po' particolare perché il codice sorgente è rilasciato con licenza GPL ma lo sviluppatore distribuisce i binari precompilati a pagamento. Ciò non è in alcun modo in contrasto con il concetto di software libero perché nella sua definizione non si parla di prezzo. La confusione di "software libero" con "software gratuito" è maggiormente presente nelle persone di lingua inglese, poiché in questa la parola "free" ha il duplice significato di "libero" e "gratuito". Anche chi usa questo software avendolo compilato da sé può fare una donazione a favore del progetto all'indirizzo http://soft.proindependent.com/why_donate.html per permettere allo sviluppatore di portare avanti il suo progetto.

In questo post spiegherò come fare a compilare QtiPlot. Questa guida è per Ubuntu Maverick Meerkat 10.10 (e probabilmente funzionerà senza troppi problemi anche per Debian), per le altre distribuzioni ci potranno essere piccoli differenze per quanto riguarda i comandi che richiamano il gestore dei pacchetti, i nomi dei pacchetti e la disponibilità di questi.

Innanzitutto cominciamo con l'installare tutte le dipendenze necessarie per la compilazione. In un terminale dare
sudo apt-get install build-essential
sudo apt-get build-dep qtiplot
Il primo comando installa (se non già presente, ma è difficile che non lo sia già) le utility necessarie per compilare la maggior parte dei programmi, il secondo installa le principali librerie che necessita QtiPlot per essere compilato. Nelle ultime versioni QtiPlot ha aggiunto altre dipendenze i cui pacchetti non sono disponibili nella versione di Ubuntu considerata, quindi prima di procedere con la compilazione di QtiPlot stesso dovremo compilare altri programmi.

Scarichiamo il codice sorgente di QtiPlot all'indirizzo http://download.berlios.de/qtiplot/qtiplot-0.9.8.4.tar.bz2. Da terminale si può usare
wget http://download.berlios.de/qtiplot/qtiplot-0.9.8.4.tar.bz2
Scompattiamo l'archivio dove ci pare (se non siete in grado di farlo da terminale, vi ricordo che è possibile farlo attraverso interfaccia grafica) e spostiamoci con il terminale nella cartella in cui si trova il sorgente:
tar xjvf qtiplot-0.9.8.4.tar.bz2
cd qtiplot-0.9.8.4/
Aprite il file README.html presente nella cartella del sorgente (è sempre buona norma leggere i file README e/o INSTALL, o simili, prima di procedere con la compilazione di un programma). Come potete vedere le dipendenze necessarie sono le seguenti: Qt (>= 4.5.0), GSL, muParser (1.32), zlib e libpng. Tutti questi pacchetti sono stati installati (se non erano già presenti) con il comando sudo apt-get build-dep qtiplot. Inoltre servono delle versioni leggermente modificate delle librerie Qwt (5.2) e QwtPlot3D, ma queste sono presenti nella sottocartella 3rdparty/ del codice sorgente di QtiPlot, quindi non bisogna scaricare nulla di nuovo per questo elencato finora. Altre librerie suggerite sono QTeXEngine, ALGLIB (2.6) e TAMUANOVA.

Compiliamo queste librerie. Salveremo i codici sorgenti di queste nella sottocartella 3rdparty/, per comodità, quindi spostiamoci in questa cartella:
cd 3rdparty/
Scarichiamo e scompattiamo l'archivio contenente il codice sorgente di QTeXEngine:
wget http://download.berlios.de/qtiplot/QTeXEngine-0.3-opensource.zip
unzip QTeXEngine-0.3-opensource.zip
cd QTeXEngine
Compiliamo la libreria (le istruzioni sono presenti nel file README.txt:
qmake
make
Se tutto è andato bene (lo potete controllare guardando l'exit status con il comando echo $?, se è 0 allora l'operazione si è conclusa correttamente) torniamo nella cartella superiore, scarichiamo il codice sorgente di ALGLIB e compiliamolo:
cd ..
wget http://www.alglib.net/translator/re/alglib-2.6.0.cpp.zip
unzip alglib-2.6.0.cpp.zip ; mv cpp alglib
cd alglib
Le istruzioni per la compilazione di questa libreria sono presenti nel file manual.cpp.html. Bisogna eseguire lo script build passando come argomento il compilatore da usare, nel nostro caso GCC. Lo script build non ha i permessi di esecuzione, quindi prima di avviarlo dobbiamo rendere il file eseguibile:
chmox +x build
./build gcc
Se anche questa operazione si è conclusa con successo (controlliamo l'exit status con echo $?: se otteniamo 0 allora è andato tutto bene) andiamo avanti possiamo compilare TAMUANOVA. Spostiamoci nella cartella superiore, scarichiamo il codice sorgente di TAMUANOVA, scompattiamo l'archivio ed entriamo nella cartella del codice sorgente di questa libreria:
cd ..
wget http://www.stat.tamu.edu/~aredd/tamuanova/tamu_anova-0.2.tar.gz
tar xzvf tamu_anova-0.2.tar.gz ; mv tamu_anova-0.2/ tamu_anova/
cd tamu_anova/
Compiliamo questa libreria (le istruzioni sono presenti nel file INSTALL):
./configure
make
Controllate l'exit status con echo $?. Se ottenete 0 la compilazione è andata a buon fine. Non è necessario installare la libreria (come neanche le precedenti), è sufficiente averla compilata. Prima di procedere dobbiamo modificare un file: 3rdparty/qwtplot3d/qwtplot3d.pro. Questo file contiene le istruzioni per la compilazione della libreria QwtPlot3D (che avverrà successivamente quando compileremo QtiPlot). Alla fine di questo file bisogna aggiungere la seguente riga:
unix:CONFIG += staticlib
affinché venga compilata staticamente (suggerimento tratto da qui).

Ritorniamo con il terminale nella cartella principale del codice sorgente di QtiPlot (che si trova due cartelle superiori rispetto alla carella di ALGLIB in cui ci trovavamo prima):
cd ../..
Prima di iniziare la compilazione vera e propria ci sono ancora diverse operazioni da fare. Prima di tutto dobbiamo creare un file chiamato build.conf da posizionare nella cartella del codice sorgente di QtiPlot e che contiene alcune istruzioni che servono per la compilazione. Questo file dovrà essere realizzato sulla base del modello build.conf.example che si trova nella stessa cartella. Per la precisione, build.conf contiene alcune opzioni e variabili per la compilazione e i percorsi delle librerie da utilizzare (oppure le corrispondenti opzioni di compilazione). In questo file la variabile QTI_ROOT è uguale al percorso della cartella principale del codice sorgente di QtiPlot. Ho modificato build.conf.example in base ai reali percorsi delle librerie utilizzate ed ecco il mio build.conf:
isEmpty( QTI_ROOT ) {
  message( "each file including this config needs to set QTI_ROOT to the dir containing this file!" )
}

##########################################################
##     System specific configuration
##########################################################

# Global include path which is always added at the end of the INCLUDEPATH
SYS_INCLUDEPATH = /opt/local/include
# Global lib path and libs which is ls always added at the end of LIBS
SYS_LIBS = -L/opt/local/lib

##########################################################
## zlib (http://www.zlib.net/)
##########################################################

# include path. leave it blank to use SYS_INCLUDE
ZLIB_INCLUDEPATH = $$QTI_ROOT/3rdparty/zlib/

##########################################################
## muParser (http://muparser.sourceforge.net/)
##########################################################

# include path. leave it blank to use SYS_INCLUDE
MUPARSER_INCLUDEPATH = /usr/include/muParser/
# link statically against a copy in 3rdparty/
MUPARSER_LIBS = /usr/lib/libmuparser.so
# or dynamically against a system-wide installation
# MUPARSER_LIBS = -lmuparser

##########################################################
## GNU Sientific Library (http://www.gnu.org/software/gsl/)
##########################################################

# include path. leave it blank to use SYS_INCLUDE
# GSL_INCLUDEPATH = $$QTI_ROOT/3rdparty/gsl/include
# link statically against a copy in 3rdparty/
# GSL_LIBS = $$QTI_ROOT/3rdparty/gsl/lib/libgsl.a \
#            $$QTI_ROOT/3rdparty/gsl/lib/libgslcblas.a
# or dynamically against a system-wide installation
GSL_LIBS = -lgsl -lgslcblas

##########################################################
## QWT - use local copy till upstream catches up
# http://qwt.sourceforge.net/index.html
##########################################################

# include path.
QWT_INCLUDEPATH = $$QTI_ROOT/3rdparty/qwt/src
# link locally against a copy in 3rdparty/
QWT_LIBS = $$QTI_ROOT/3rdparty/qwt/lib/libqwt.a

##########################################################
## QwtPlot3D - use local copy till upstream catches up
# http://qwtplot3d.sourceforge.net/
##########################################################

# include path.
QWT3D_INCLUDEPATH = $$QTI_ROOT/3rdparty/qwtplot3d/include
# link locally against a copy in 3rdparty/
win32:QWT3D_LIBS = $$QTI_ROOT/3rdparty/qwtplot3d/lib/qwtplot3d.dll
unix:QWT3D_LIBS = $$QTI_ROOT/3rdparty/qwtplot3d/lib/libqwtplot3d.a

##########################################################
## libpng - optional. you don't have to set these variables
##########################################################

# include path. leave it blank to use SYS_INCLUDE
# LIBPNG_INCLUDEPATH = $$QTI_ROOT/3rdparty/libpng/
# link statically against a copy in 3rdparty/
# LIBPNG_LIBS = $$QTI_ROOT/3rdparty/libpng/libpng.a
# or dynamically against a system-wide installation
LIBPNG_LIBS = -lpng

##########################################################
## QTeXEngine - optional. you don't have to set these variables
# http://soft.proindependent.com/qtexengine/
##########################################################

# include path.
TEX_ENGINE_INCLUDEPATH = $$QTI_ROOT/3rdparty/QTeXEngine/src
# link locally against a copy in 3rdparty/
TEX_ENGINE_LIBS = $$QTI_ROOT/3rdparty/QTeXEngine/libQTeXEngine.a

##########################################################
## ALGLIB (2.6) - optional. you don't have to set these variables
# http://www.alglib.net/
##########################################################

# include path.
ALGLIB_INCLUDEPATH = $$QTI_ROOT/3rdparty/alglib/src
# link locally against a copy in 3rdparty/
ALGLIB_LIBS = $$QTI_ROOT/3rdparty/alglib/out/libalglib.a

##########################################################
## TAMUANOVA - optional. you don't have to set these variables
# http://www.stat.tamu.edu/~aredd/tamuanova/
##########################################################

# include path.
TAMUANOVA_INCLUDEPATH = $$QTI_ROOT/3rdparty/tamu_anova/
# link locally against a copy in 3rdparty/
TAMUANOVA_LIBS = $$QTI_ROOT/3rdparty/tamu_anova/libtamuanova.a

##########################################################
## python - only used if python is needed
##########################################################

# the python interpreter to use
# (unix only, windows will use what ever is configured to execute .py files!)
PYTHON = python

##########################################################
## Qt tools - allows to use specific versions
##########################################################

LUPDATE = lupdate
LRELEASE = lrelease

############################################################
##  Target specific configuration: configure Qtiplot itself
############################################################

contains( TARGET, qtiplot ) {
  # building without muParser doesn't work yet
  SCRIPTING_LANGS += muParser
  SCRIPTING_LANGS += Python

  # a console displaying output of scripts; particularly useful on Windows
  # where running QtiPlot from a terminal is inconvenient
  DEFINES         += SCRIPTING_CONSOLE

  #DEFINES         += QTIPLOT_DEMO

  # Uncomment the following line if you want to perform a custom installation using the *.path variables defined in ./qtiplot.pro.
  #CONFIG          += CustomInstall

  # Uncomment the following line if you want to build QtiPlot as a browser plugin (not working on Internet Explorer).
  #CONFIG          += BrowserPlugin
  
  CONFIG          += release
  #CONFIG          += debug
  
  # Uncomment the following line if you want to link statically against Qt.
  #CONFIG           += StaticBuild
  #win32: CONFIG   += console
}

Non abbiamo ancora finito, dobbiamo fare un'ultima cosa. Modifichiamo il file qtiplot.pro che si trova nella cartella principale del codice sorgente. Questo contiene il nome di quali cartelle contengono del codice che dovrà essere compilato. Togliamo dall'elenco fitPlugins e manual (eventualmente potranno essere compilati successivamente), quindi il file apparirà più o meno così:
TEMPLATE = subdirs

SUBDIRS = 3rdparty/qwt \
        3rdparty/qwtplot3d \
        qtiplot
A questo punto dovremmo essere in grado, finalmente di compilare QtiPlot. Come spiegato nel file README.html i comandi da dare sono
qmake
make
Per rendere più veloce la compilazione, chi ha un processore multicore può passare a make l'opzione -j n, dove n è il numero di core del processore (o meglio di job simultanei che può gestire, però per semplificare il discorso parliamo di core). Quindi chi, per esempio, ha un processore con quattro core potrà usare per compilare QtiPlot il comando
make -j 4
Se la compilazione va a buon fine (come al solito possiamo controllarlo con echo $?) possiamo direttamente avviare QtiPlot, per vedere se funziona, inserendo il percorso relativo dell'eseguibile appena generato:
qtiplot/qtiplot
Infine si può, se lo si desidera, installare il programma con
sudo make install
oppure utilizzando checkinstall:
sudo checkinstall
che crea un semplice pacchetto .deb (il risultato, però, non è "professionale").

sabato 19 febbraio 2011

Emacs: aprire il file manager nella cartelle del buffer corrente

In Emacs è presente una modalità chiamata Dired che funge da file manager. Tuttavia in qualche caso si potrebbe voler aprire il file manager dell'ambiente desktop in uso (o comunque un file manager esterno) direttamente nella cartella in cui si trova il file attualmente modificato (o meglio, il buffer corrispondente). Per fare ciò si può aggiungere il seguente codice all'interno del proprio file di inizializzazione (a meno che questa funzione non sia già presente in Emacs e io non sia in grado di trovarla):
(defun open-buffer-path ()
  "Run Nautilus on the directory of the current buffer."
  (interactive)
  (shell-command (concat "nautilus " default-directory)))
Questo codice definisce la funzione open-buffer-path che aprirà il file manager Nautilus (il predefinito di GNOME) nella cartella predefinita (che normalmente corrisponde alla cartella in cui si trova il file in uso, oppure alla propria home se il buffer aperto non corrisponde a un file). Se si vuole usare un file manager diverso basta sostituire il comando che compare come argomento di concat (e magari anche il Nautilus che compare nel rigo di descrizione della funzione).

Se lo si desidera si può associare una combinazione di tasti a questa funzione aggiungendo al proprio file di inizializzazione:
(global-set-key (kbd "<M-f3>") 'open-buffer-path)
Con questo codice verrà associata la combinazione M-f3 alla funzione open-buffer-path, se si vuole usare una combinazione diversa basta sostituire l'occorrenza di M-f3 nel codice precedente.

Questo post prende spunto da http://zhangda.wordpress.com/2010/02/03/open-the-path-of-the-current-buffer-within-emacs/ in cui è definita una funzione per aprire il file manager Explorer in Windows. A questo proposito trovate un codice alternativo qui: http://www.factsandpeople.com/facts-mainmenu-5/2-editor-emacs/80-switching-between-windows-explorer-and-emacs.

sabato 15 gennaio 2011

info: Impossibile trovare il nodo «Top». [Risolto]

Non so bene per quale motivo (ma ho l'impressione che sia colpa di un aggiornamento di Ubuntu) non sono più in grado di usare info. Come spiegai in uno dei primi post di questo blog, per consultare da terminale i manuali (se presenti) dei comandi si può usare man:
man nomecomando
In aggiunta a man, molti programmi (soprattutto del progetto GNU) forniscono una guida (spesso più completa del manuale consultabile con man) che può essere letta con info:
info nomecomando
In questi giorni, dando il comando (per esempio)
info coreutils
(per leggere la guida delle principale utilità di sistema, chiamate appunto coreutils) ricevo dal terminale questa risposta:
info: Impossibile trovare il nodo «Top».
Il messaggio in lingua inglese è il seguente:
info: Cannot find node `Top'.
Il problema è che per qualche motivo si è corrotto il file /usr/share/info/dir che contiene (o, nel mio caso, dovrebbe contenere) l'elenco dei manuali che possono essere consultati con info. Il mio file /usr/share/info/dir conteneva solo questo:
Questo è il file .../info/dir, che contiene il
nodo più in alto della gerarchia di Info, chiamata (dir)Top.
La prima volta che invochi il programma Info esso parte da questo nodo.
^_
File: dir, Node: Top\tQuesto è il nodo più alto dell'albero INFO

Questo (il nodo principale) fornisce un menù che contiene le voci principali.
Digitando "q" esce, digitando "?" si produce un elenco di tutti i comandi Info,
"d" ritorna alla presente schermata, "h" fornisce informazioni ai nuovi utenti,
"mEmacs<return>" visualizza il manuale di Emacs, ecc.
All'interno di Emacs, puoi cliccare con il pulsante sinistro del mouse su una voce di menù
o su un riferimento incrociato per selezionarlo.

* Menu:
Come vedete, manca l'elenco dei manuali disponibili, che invece dovrebbe essere presente dopo la riga * Menu:.

Per risolvere il problema si può cancellare il file incriminato e rigenerarlo con il comando da terminale install-info (in Debian, Ubuntu e derivate bisogna richiamare il comando con ginstall-info). install-info accetta come primo argomento il file (in genere questi file hanno estensione .info e potrebbero essere compressi con gzip) che contiene il manuale che si vuole aggiungere all'elenco (questi file in genere si trovano nella cartella /usr/share/info/ e sue sottocartelle), come secondo argomento il file di elenco (cioè /usr/share/info/dir). Queste due operazioni possono essere automatizzate con i due seguenti comandi (richiedono i diritti di amministratore perché si modificherà un file di sistema):
sudo mv /usr/share/info/dir ~/dir
for file in /usr/share/info/*.{gz,info} /usr/share/info/*/*.{gz,info}; do sudo install-info "$file" /usr/share/info/dir; done
Se usate sistemi, come Debian o Ubuntu, che richiedono ginstall-info al posto di install-info, il secondo dei comandi precedenti va cambiato in
for file in /usr/share/info/*.{gz,info} /usr/share/info/*/*.{gz,info}; do sudo ginstall-info "$file" /usr/share/info/dir ; done
Breve spiegazione dei comandi consigliati: il primo comando (mv) serve per spostare il file nella propria home, conservando una copia di sicurezza (anche se il file è corrotto non fa male creare una copia, dopo aver risolto il problema la copia può essere tranquillamente cancellata); il secondo esegue un ciclo for su tutti i file con estensioni .gz o .info presenti nella cartella /usr/share/info sue sottocartelle. Se in questo modo non dovessero essere inclusi alcuni file di manuali, potete farlo manualmente tramite install-info (o ginstall-info) con la sintassi esposta precedentemente.

Aggiornamento importante: dopo il commento di Zio LoneWolf (che ringrazio) mi sono accorto che la questione era più complicata di quanto mi sembrasse inizialmente. Per risolvere il problema non è affatto sufficiente usare i comandi presentati in precedenza perché pare che sia presente un bug nella traduzione italiana di Texinfo. Si può aggirare (e questa volta per davvero) il problema impostando nella shell la lingua inglese e poi utilizzando nuovamente i comandi precedenti:
LANG=en_US.UTF-8
for file in /usr/share/info/*.{gz,info} /usr/share/info/*/*.{gz,info}; do sudo install-info "$file" /usr/share/info/dir; done
oppure
LANG=en_US.UTF-8
for file in /usr/share/info/*.{gz,info} /usr/share/info/*/*.{gz,info}; do sudo ginstall-info "$file" /usr/share/info/dir; done
L'aggiornamento del file /usr/share/info/dir può anche essere fatto con il comando update-info-dir (dato come al solito con privilegi di amministratore). Si può fare in modo che questo script utilizzi sempre la lingua inglese senza doverla impostare manualmente ogni volta. Aprite con il vostro editor di testo preferito (e con i diritti di amministratore) lo script /usr/sbin/update-info-dir. Per esempio con gedit si userà:
gksudo gedit /usr/sbin/update-info-dir
A questo punto inserite la stringa
unset LANG # https://bugs.launchpad.net/ubuntu/+source/texinfo/+bug/707931
(nel commento c'è un riferimento alla segnalazione del bug su Launchpad) per esempio dopo il rigo
unset LANGUAGE
Dopo di ciò sarà possibile aggiornare il file /usr/share/info/dir semplicemente con il comando
sudo update-info-dir
Altro aggiornamento: Giovanni segnala nei commenti che ha realizzato uno script per risolvere automaticamente il problema. Trovate lo script e le istruzioni per l'uso sul sito sito: http://www.ubaweb.it/miniguide/info_non_va.php.