Debian backports. Software nuovo su Debian stable

I backports

You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions.

Il prezzo della stabilità è l’utilizzo di software non proprio aggiornatissimo…

Grazie al progetto Debian backports anche gli assetati di stabilità potranno godere di software recente! Sto parlando sia di versioni di software più nuove rispetto all’uscita della Debian stable e pertanto in essa non contenuti (è il caso di openoffice 3.0), sia di software che per un motivo o per un altro non è stato inserito nella stable (è il caso di wicd)

Come funzionano i backports?

Il repository backports contiene software recente, proveniente dal ramo testing o raramente anche da sid, che è stato ricompilato compatibilmente con le librerie presenti nella stable. Da ciò deriva che non è necessario aggiornare le librerie fondamentali del sistema per avere le nuove versioni dei programmi! Ovviamente ciò  sarà impossibile per alcuni programmi…  Tutti gli altri li troviamo nei backports e ce li possiamo godere con relativa tranquillità in un sistema considerabile stabile.

L’utilità dei backports è tanto più alta quanto più la stable invecchia. Già adesso comunque possiamo trovarci Open Office 3.0.1, wicd e molti altri pacchetti che possiamo ricercare da qui.

Utilizzare i backports

Come prima cosa si aggiunge la seguente stringa al file /etc/apt/sources.list per abilitare il repository:

deb http://www.backports.org/debian lenny-backports main contrib non-free

Quindi si aggiorna l’elenco dei pacchetti:

# aptitude update

Si installa il pacchetto contenente la chiave gpg di validazione del repository:

# aptitude install debian-backports-keyring

# aptitude update

Si installa il pacchetto che si vuole dai backports con il semplice comando:

# aptitude -t lenny-backports install pacchetto

Poi se vogliamo che in automatico vengano installate le versioni dei pacchetti provenienti da backports modifichiamo il file /etc/apt/preferences aggiungendo le seguenti  (3) righe:

Package: *
Pin: release a=lenny-backports
Pin-Priority: 1001

Oppure se ci accontentiamo di mantenere aggiornati soltanto i pacchetti che abbiamo installato manualmente impostiamo la Pin-Priority al valore di 200 . Poi aggiorniamo il sistema:

# aptitude upgrade

Esempio pratico:

sostituire (k)network-manager con wicd

E’  innegabile l’utilità di un gestore grafico della rete qualora ci si sposti spesso con il proprio laptop, soprattutto se ci si  deve confrontare con molte reti, sia cablate che wireless.  Tra questi strumenti, quello che mi ha attirato maggiormente è l’onnipotente wicd:  completo, semplice e facile da utilizzare, si porta dietro pochissime dipendenze e quindi si integra perfettamente su ogni DE, compreso il mio Xfce! Ottimo sostituto per il fastidiosissimo network-manager e derivati 😉

Di fatto wicd non è presente nei repository della stable. Questo ci dà modo di testare i backports appena configurati!

In perfetto stile Debian l’installazione si fa con un singolo comando!

# aptitude -t lenny-backports install wicd

A questo punto non resta che disabilitare il vecchio  gestore grafico della rete e cominciare ad usare con profitto quello nuovo!

happy debian, happy hacking

Installare java 6 su Debian Lenny amd64 con plugin per Firefox/Iceweasel/Seamonkey a 64 bit

…Questo post soltanto pochi mesi fa sarebbe stato chilometrico…  Soltanto in tempi relativamente recenti SUN ha reso disponibile  Java a 64 bit.

Beffa:  non esisteva comunque nessun plugin per il browser a 64 bit, che ci costringeva ad installare altre macchine virtuali molto poco ben digerite dal web che ci circonda.
Dal 12 febbraio 2009 in contemporanea all’update della jre (Sun Java(TM) Runtime Environment 6 ), è apparso nei repository ufficiali di Lenny  anche il java-plugin per i browser Mozilla.

Grazie a Debian oggi ci possiamo permettere di installare la jre e relativo plugin con un singolo comando!

# aptitude install sun-java6-jre sun-java6-plugin

Se la jre non ci basta e vogliamo la jdk basta modificare opportunamente il comando sopra.

Avvio automatico di Xfce, senza gestore grafico di login (con o senza password)

C’è chi, come me, ritiene superfluo il ricorso ai gestori grafici del login (xdm, gdm, kdm, slim). Adoro il minimalismo e le cose semplici e poco cervellotiche.

Il seguente trucco ci permetterà di avviare il Desktop Environment Xfce4 in automatico, subito dopo il login testuale sulla tty1 che ci viene presentata.

Semplicemente modifichiamo il file ~/.bashrc del nostro utente inserendo in coda le seguenti righe:

if [ "`tty`" = "/dev/tty1" ]
then
startxfce4 1>/tmp/startxfce.log 2>&1
fi

La sintassi è facilmente interpretabile. Inoltre così facendo salviamo un log dell’avvio in  /tmp/startxfce.log dove andremo a ricercare gli eventuali errori di sessione, con il vantaggio ulteriore che allo shutdown troveremo la tty1 pulita (possibile ridirezionarli anche a /dev/null o dove altro vogliamo).

Se abbiamo la certezza che **NESSUNO** possa accedere indebitamente al nostro computer (vuoi perché chi ci è intorno non sa cosa sia questo scatolotto “davanti” al quale perdiamo le nostre notti, vuoi perché viviamo da soli, vuoi perché teniamo sotto chiave) esiste un metodo tutt’altro che sicuro che permette di avviare la sessione di Xfce del nostro utente, in automatico e senza il bisogno di inserire alcuna password.

Se questo è ciò che vogliamo, allora modifichiamo come root il file /etc/inittab aggiungendo la seguente stringa alla fine del file stesso:

x:2:once:/bin/su nostro_utente -l -c "/bin/bash --login -c startxfce4 >/dev/null 2>/dev/null"

ovviamente sostituiamo  nostro_utente con il nome vero del nostro utente. In questo modo, alla fine del runlevel 2 ovvero quello di avvio di default, verrà  lanciato una singola volta (once) il comando a destra dei “:” che consente di avviare una sessione di Xfce con il  nostro utente. Gli output sono ridirezionati in questo esempio a /dev/null, mio device preferito 😉

Happy debian, happy hacking

Cambiare estensione a più file contemporaneamente. Convertire stock di immagini in diversi formati

Come cambiare contemporaneamente  l’estensione a tutti i file di un certo tipo nella directory di lavoro?? Semplice!

Ammettiamo di voler cambiare l’estensione di tutti i file .dat in .txt :

for f in *.dat; do mv "$f" "${f/%.dat/.txt}"; done

Similmente si può cambiare formato ad uno stock di immagini sfruttando le potenzialità del pacchetto imagemagick.

Per convertire tutte le immagini .jpg in formato png è sufficiente:

for f in *.jpg; do convert "$f" "${f/%.jpg/.png}"; done

In entrambi i casi non ci sono problemi con l’uso di spazi nel nome dei file.

OCR perfetto con tesseract

tesseract – command line OCR tool

…così inizia il manuale di tesseract.

Tesseract è un motore di OCR (Optical Character Recognition) libero, o per meglio dire “liberato”.  Sviluppato dalla Hewlett-Packard tra il 1985 e il 1995, è stato abbandonato a se stesso per i successivi 10 anni, fino a quando nel 2005 ne è stato rilasciato il codice sorgente con una licenza libera. La licenza in questione è la Apache License, Version 2.0, che la FSF considera “a free software license, compatible with version 3 of the GPL“.

Questo ha suscitato un nuovo interesse verso questo affascinante motore che attualmente viene sviluppato nientemeno che da Google.

Punto di forza

è considerato uno dei più accurati motori OCR attualmente disponibili, con il vantaggio non indifferente che essendo free software è accessibile e utilizzabile da tutti. Supporta molte lingue: Italiano, Inglese, Francese, Tedesco, Spagnolo, etc.

Installazione:

In stile debian, con un singolo comando è possibile installare tesseract e i language file che ci intereaasano.

# aptitude install tesseract-ocr tesseract-ocr-ita

File di input

L’immagine di input che può provenire ad esempio da una scansione di un documento può essere un bitmap (.bmp) o meglio ancora un tiff (.tif). Nessuna restrizione sul colore anche se devo dire che ho trovato che lavora meglio su file in scala di grigi e ritoccati in modo da avere il maggior contrasto possibile tra testo e sfondo senza però che si perda di definizione.
Con GIMP queste ottimizzazioni si fanno in un batter d’occhio!

Portare in scala di grigi: Immagine -> Modalità -> Scala di grigi…

Modifica della soglia:  Strumenti -> Colore -> Soglia…

Utilizzo

Ancora più banale… Sia input.tif il file di input, si specifica con -l la lingua nella quale è scritto il documento (di default: eng) a scelta tra quelle che abbiamo installato:

$ tesseract input.tif output -l ita

Nell’esempio sopra il programma avrà generato nella directory di lavoro un file di testo output.txt contenente l’OCR della nostra scansione.

Questo è l’utilizzo più banale di questo formidabile motore OCR.

happy debian, happy hacking

Skype su Debian Lenny AMD64

Tralascerò il fatto che a tutt’oggi non è stata rilasciata nessuna versione di Skype, compilata per la nostra amata architettura a 64 bit.
Poco male! I processori X86-64 (AMD64/EM64T) mantengono piena compatibilità con le istruzioni X86, di conseguenza è possibile eseguire codice binario a 32 bit, pur avendo installato un sistema operativo a 64 bit.
Tutto questo, grazie al fatto che il kernel Linux lo permette e a patto di avere installate tutte le librerie a 32 bit necessarie.

Prepariamo il nostro sistema

Debian ci viene enormemente incontro, dandoci la possibilità di installare in un sol colpo tutte le librerie a 32 bit necessarie a moltissimi programmi a 32 bit. Con un attimo di ammirazione diamo un bel :

# aptitude install ia32-libs ia32-libs-gtk libc6-i386 lib32asound2 lib32gcc1 lib32z1 gsfonts-X11

Poi andiamo sul sito ufficiale di Skype e ci scarichiamo la versione di skype compilata staticamente che chiamano Static. Vogliamo questa perché è la più versatile e perché non soffre del noto bug che non ci permette di vedere gli avatar dei nostri contatti.

Il file è un .tar.bz2 che decomprimiamo come nostra abitudine in una directory a nostro piacimento. Ammettiamo che questa sia /opt/. Dal processo di estrazione verrà creata la  directory /opt/skype_static-2.0.0.72 in cui troviamo vari file tra cui l’eseguibile vero e proprio, skype di circa 20 MB .  Ovviamente può essere decompresso in una directory qualunque, basta poi modificare i comandi esposti successivamente di conseguenza.

Verifica delle librerie

controlliamo che l’eseguibile veda tutte le librerie:

samuele@impero-main:/opt/skype_static-2.0.0.72$ ldd skype
linux-gate.so.1 => (0xf7fb4000)
libasound.so.2 => /usr/lib32/libasound.so.2 (0xf7ed7000)
libXv.so.1 => /usr/lib32/libXv.so.1 (0xf7ed2000)
libXss.so.1 => /usr/lib32/libXss.so.1 (0xf7ecf000)
libSM.so.6 => /usr/lib32/libSM.so.6 (0xf7ec7000)
libICE.so.6 => /usr/lib32/libICE.so.6 (0xf7eaf000)
libXi.so.6 => /usr/lib32/libXi.so.6 (0xf7ea7000)
libXrender.so.1 => /usr/lib32/libXrender.so.1 (0xf7e9e000)
libXrandr.so.2 => /usr/lib32/libXrandr.so.2 (0xf7e98000)
libXfixes.so.3 => /usr/lib32/libXfixes.so.3 (0xf7e93000)
libXcursor.so.1 => /usr/lib32/libXcursor.so.1 (0xf7e8a000)
libXinerama.so.1 => /usr/lib32/libXinerama.so.1 (0xf7e86000)
libfreetype.so.6 => /usr/lib32/libfreetype.so.6 (0xf7e11000)
libfontconfig.so.1 => /usr/lib32/libfontconfig.so.1 (0xf7de7000)
libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7dd9000)
libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7cea000)
librt.so.1 => /lib32/librt.so.1 (0xf7ce1000)
libdl.so.2 => /lib32/libdl.so.2 (0xf7cdc000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf7cc5000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7bd7000)
libm.so.6 => /lib32/libm.so.6 (0xf7bb3000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7ba6000)
libc.so.6 => /lib32/libc.so.6 (0xf7a54000)
libz.so.1 => /usr/lib32/libz.so.1 (0xf7a3e000)
libexpat.so.1 => /usr/lib32/libexpat.so.1 (0xf7a18000)
libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7a15000)
libxcb-xlib.so.0 => /usr/lib32/libxcb-xlib.so.0 (0xf7a13000)
libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf79fb000)
/lib/ld-linux.so.2 (0xf7fb5000)
libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf79f5000)

Questa è solo una verifica in quanto tutte le librerie a 32 bit necessarie a skype sono contenute nei pacchetti elencati sopra.

Eseguire skype

Perché  il programma funzioni perfettamente è necessario appendere al comando di esecuzione un’opzione che indichi al programma la directory delle sue risorse.Sia /opt/skype_static-2.0.0.72 la directory di installazione avviamo skype mediante:

samuele@impero-main:~$ /opt/skype_static-2.0.0.72/skype --resources=/opt/skype_static-2.0.0.72/

Questo è da tenere conto anche se si ha intenzione di creare un avviatore personalizzato (sul desktop, menù o in /usr/bin/ che sia) che dovrà recare la stessa opzione.

happy debian, happy hacking

Invio e ricezione di file tramite bluetooth, da shell – Pt 2

Configurato il sistema come spiegato nel precedente post non resta che passare al sodo!

Invio dei file verso il cellulare

Queste cose le facciamo solo alla prima connessione.

Per impostare la password bluetooth si agisce sul file /etc/bluetooth/hcid.conf modificando opportunamente la seguente stringa:

# Default PIN code for incoming connections
passkey "1234";

Io per comodità non uso password. Per fare questo è necessario settare nello stesso file:

# Security Manager mode
# none - Security manager disabled
# auto - Use local PIN for incoming connections
# user - Always ask user for a PIN
#
security none;

Accendiamo il bluetooth del cellulare e facciamo partire una scansione sul PC.

samuele@impero-main:~$ hcitool scan
Scanning ...
00:1C:43:03:C6:E6 bubburuba-da-tasca

Come si vede è stato rilevato il mio cellulare che ho chiamato bubburuba-da-tasca. La stringa di numeri è il fondamentale ID del dispositivo.

Adesso identifichiamo il canale che il cellulare usa per il protocollo OBEX opject push:

samuele@impero-main:~$ sdptool browse
Inquiring ...
...
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 7
"OBEX" (0x0008)
Profile Descriptor List:
"OBEX Object Push" (0x1105)
Version: 0x0100.

...

Il canale risulta essere il n° 7.

Adesso abbiamo le conoscenze necessarie per inviare un file al nostro cellulare. Basta il seguente comando, identico per ognuna delle volte successive che dovremmo inviare un file al nostro cellulare:

samuele@impero-main:~$ obexftp -b [id device] -B [canale] -p [file da inviare]

Se avete un telefono bastardo quanto il mio samsung, otterrete il seguente errore:

samuele@impero-main:~$ obexftp -b 00:1C:43:03:C6:E6 -B 7 -p trillo.mp3
Browsing 00:1C:43:03:C6:E6 ...
Channel: 7
Connecting...failed: FBS UUID
Still trying to connect


Fortunatamente si risolve utilizzando le opzioni -U NONE -H -S, ovvero:

samuele@impero-main:~$ obexftp -U NONE -H -S -b 00:1C:43:03:C6:E6 -B 7 -p trillo.mp3
Suppressing FBS.
Browsing 00:1C:43:03:C6:E6 ...
Channel: 7
Connecting...done
Sending "trillo.mp3"...-done

…il trasferimento va a gonfie vele!!!!

Ricezione dei file dal cellulare

Semplicemente si lancia il comando obexpushd, da utente:

samuele@impero-main:~$ obexpushd

Il nostro PC sarà visibile dal cellulare e sarà recettivo ai file che gli invieremo dal cellulare stesso. Questi verranno salvati nella directory di lavoro (quella da cui abbiamo lanciato il comando obexpushd, quindi nel mio caso la home) .

Invio e ricezione di file tramite bluetooth, da shell

Dopo una frettolosa lettura di questo post, riusciremo a far comunicare la nostra Debian Lenny con il nostro cellulare via bluetooth.  Con le modifiche del caso, la guida si applica ad ogni altra distribuzione GNU/Linux e probabilmente anche a freeBSD derivate. Tutto senza bisogno di avere il server X in funzione. In altre parole, si fa tutto da shell.

Necessario:

• Adattatore bluetooth usb.
• Cellulare bluetooth
• PC 😉

Da installare…

Su Debian lenny, è sufficiente installare via aptitude i seguenti pacchetti:

• bluez-utils : lo stack di protocollo Bluetooth ufficiale per Linux
• obexftp :  utility per il trasferimento di file mediante il protocollo OBEX verso il cellulare
• obexpushd : programma per ricevere file via Bluetooth sul PC dal cellulare
• bluez-firmware : firmware necessari per il funzionamento di moltissimi adattatori bluetooth.

set-up

Installati i componenti fondamentali, si inserisce l’adattatore USB nell’apposito foro presente sul nostro PC atto ad accogliere dispositivi USB.

Con la stessa naturalezza verifichiamo se il kernel ha digerito la cosa:

samuele@impero-main:~$ dmesg|tail
...
usb 2-8: new full speed USB device using ohci_hcd and address 5
usb 2-8: configuration #1 chosen from 1 choice
Bluetooth: Core ver 2.11
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: HCI USB driver ver 2.9
usbcore: registered new interface driver hci_usb

Nel mio caso la cosa è stata digerita. Adesso, da root lanciamo hcid, il demone che si occupa del bluetooth:

impero-main:/home/samuele# /etc/init.d/bluetooth start
Starting bluetooth: hcid.

Verifichiamo che il kernel abbia fatto il suo dovere, ovvero se l’adattatore è stato riconosciuto come tale:

samuele@impero-main:~$ dmesg|tail
...

Bluetooth: L2CAP ver 2.9
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8


La strada è adesso in discesa.

seconda parte: Invio e ricezione di file

32 o 64 bit??

Questo post (dato che è il primo vero post!)  vuole fare un po’ di chiarezza in merito ad alcuni aspetti riguardanti il riconoscimento dell’architettura del proprio processore (ripeto: processore e non sistema operativo!).

Le architetture oggi più diffuse tra i nostri PC sono fondamentalmente due:

• i386 (X86, a 32 bit)
• amd64 (X86-64 : AMD64/EM64T, a 64 bit)

(Ci sono migliaia di modi per riferirsi a queste, alcuni nemmeno troppo adeguati…)

Come capisco se il processore che ho ha  l’estensione AMD64, altresì detta x86-64,  quindi se supporta istruzioni a 64 bit (AMD&4 o EM64T che sia…)?

Modo n°1 : cercare informazioni in rete  sul proprio processore ( aka RTFM!).

Metodo n°2 : Può essere divertente fare tutto in autonomia.

Ammettiamo di avere la possibilità di accedere ad una shell sulla nostra macchina. Questo  è sempre possibile in quanto anche se abbiamo appena sballato il nostro nuovo computer e non abbiamo ancora fatto in tempo ad installare la nostra distribuzione GNU/Linux preferita  (n.d.r.:  a questo punto si dovrebbe sorridere dato che si dà per scontato che la norma sia che ogni lettore di questo post interessato al suo contenuto, abbia installato sulla propria macchina una distribuzione GNU/Linux) , possiamo scaricare e lanciare  una live GNU/Linux qualunque (ce ne sono decine, debian compresa). Ricordo che una live a 32 bit (ovvero i386) può girare sia su processori X86 che x86-64.

Preso il possesso di una shell possiamo passare all’attacco:

Il primo semplice metodo consiste nell’analizzare la sezione flags del file /proc/cpuinfo alla ricerca del flag lm (long mode) che se presente è indice del fatto che il nostro processore è x86-64 compatibile.

samuele@impero-main:~$cat /proc/cpuinfo
...
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr lahf_lm
...

Infatti come è spiegato nel  file

/usr/src/linux-headers-$(uname -r)/include/asm-x86/cpufeature.h

dove è riportata una breve descrizione del significato dei vari flag, il flag lm sta ad indicare:

#define X86_FEATURE_LM    (1*32+29) /* Long Mode (x86-64) */

…ovvero che il processore è “a 64 bit” e supporta il set di istruzioni AMD64/EM64T.  Se non è presente il processore è un x86 a 32 bit.

Nota: clflush size non dà modo alcuno di identificare l’architettura del processore (come invece viene riportato spesso in rete)

Post #0

Ebbene sì. Ci sono.

Questo è il mio primo fugace e frettoloso post.

Vi dirò quanto più possibile su di me:


samuele@impero-main:~$ uname -a

Linux impero-main 2.6.26-core2-duo #1 SMP PREEMPT Sat Oct 18 17:55:54 GMT 2008 x86_64 GNU/Linux


samuele@impero-main:~$ cat /etc/debian_version
5.0