Forum Debianizzati

Condividi contenuti
Aggiornato: 53 min 2 sec fa

Re: Aggiornare...tempi lunghissimi.

Gio, 03/07/2014 - 09:47
Sono io che mi sono espresso da cane, intendevo dire che non credo che sia facile che si sia corrotto.
Categorie: Forum Debianizzati

Re: Aggiornare...tempi lunghissimi.

Gio, 03/07/2014 - 09:46
@Palo_Pd Una curiosità: mentre aggiornavi con aptitude avevi la macchina inchodata con un load average elevatissimo? Anche io passando ad apt-get penso di aver risolto, ormai sono quasi due settimane che la mia macchina ha delle prestazioni decenti.
Categorie: Forum Debianizzati

Re: Aggiornare...tempi lunghissimi.

Gio, 03/07/2014 - 09:33
Disinstallato aptitude e aggiornato tutto con apt in tempi veloci, nonostante le innumerevoli righe di aggiornamento.
@marcomg: perché non dovrebbe essere facile reinstallare aptitude?

Grazie
Categorie: Forum Debianizzati

Re: problemi auto mount

Mer, 02/07/2014 - 23:26
Dai log che hai inviato non si può verificare la corrispondenza tra UUID e device che hai indicato.

Potrebbe essere utile commentare le righe relative al mount dei dischi /dev/sdb e /dev/sdc , impartire manualmente il comandi di mount e visionare il log di comandi impartiti per individuare eventuali anomalie.
Categorie: Forum Debianizzati

Re: weekly builds

Mer, 02/07/2014 - 22:14
Presumo che quel "gnome" stia a significare che il cd in questione contiene i pacchetti di gnome e non che il desktop di default sia gnome.
Categorie: Forum Debianizzati

weekly builds

Mer, 02/07/2014 - 21:38
qualcuno mi sa spiegare perchè se io mi scarico da qui http://cdimage.debian.org/cdimage/weekl ... 64/iso-cd/ la iso della versione gnome, poi alla fine mi ritrovo invece di gnome con xfce? E la cosa non è di adesso ma va avanti da quando hanno cambiato il De di defaul. Ogni volta che mi è servita quell'iso speravo che avessaro sistemato la cosa, ma vedo che ancora è sempre la stessa storia. Non mi è difficile installare gnome e purgare xfce, ma vorrei risparmiarmi questa scocciatura la prossima volta.
Categorie: Forum Debianizzati

Re: [RISOLTO] tar exclude

Mer, 02/07/2014 - 14:32
Curiosità: ma se provi a dare

tar -cvf ecc. ecc.


senza redirigere l'output?
Categorie: Forum Debianizzati

Re: tar exclude

Mer, 02/07/2014 - 13:26
ok forse ci siamo, ho corretto in questo modo ed ora pare funzionare correttamente:

tar -cf /percorso/file.tar /percorso/dir/da/backuppare --exclude percorso/dir/da/escludere 2>/dev/null


ho solo rediretto lo stderr su /dev/null

grazie a tutti per l'aiuto

p.s.: tar 1.27.1-2
Categorie: Forum Debianizzati

Re: tar exclude

Mer, 02/07/2014 - 13:01
Confermo che il comando di Underpass funziona. Forse usiamo una versione diversa di tar?

Per conferma, prova così:

$ mkdir -p prova/dir{1,2} && touch prova/dir{1,2}/file

(Il comando crea una directory prova contenente due directory, ciascuna contenente un file vuoto.)

Ora dai:

$ tar cf prova.tar prova --exclude prova/dir2 && tar tf prova.tar

E riporta l'output. La directory dir2 viene saltata con tar (versione: 1.26+dfsg-0.1) dei repository di Wheezy.
Categorie: Forum Debianizzati

Re: tar exclude

Mer, 02/07/2014 - 11:39
Underpass ha scritto:Usato poche volte, ma è in uno script che uso per il backup del profilo di Firefox: il comando dovrebbe essere

tar -cf /percorso/file.tar /percorso/dir/da/backuppare --exclude percorso/dir/da/escludere


niet, pur usando la sintassi suggerita tar continua imperterrito ad includere anche la dir che vorrei escludere dal processo.
Categorie: Forum Debianizzati

log inviati Re: problemi auto mount

Mer, 02/07/2014 - 08:32
ciao Aki,
ho inviato i log come di seguito.
grazie
ciao
Paolo
Il log è consultabile ai seguenti indirizzi:
.. inviato pastebin.0 all'indirizzo http://paste.debian.net/107700/
.. inviato pastebin.1 all'indirizzo http://paste.debian.net/107701/
.. inviato pastebin.2 all'indirizzo http://paste.debian.net/107702/

p.s. nel Pannello di controllo del Forum nelle Preferenze Messaggi ho attivato "Avvertimi sempre quando viene scritta una risposta:" ma non mi arriva nessun avviso..mah!
Categorie: Forum Debianizzati

Re: tar exclude

Mer, 02/07/2014 - 06:43
Usato poche volte, ma è in uno script che uso per il backup del profilo di Firefox: il comando dovrebbe essere

tar -cf /percorso/file.tar /percorso/dir/da/backuppare --exclude percorso/dir/da/escludere
Categorie: Forum Debianizzati

[RISOLTO] tar exclude

Mer, 02/07/2014 - 02:21
un saluto a tutti

dunque l'oggetto della discussione è (all'apparenza) molto semplice, ho la necessità di fare un backup con tar (1.27.1-2) di una irectory all'interno della quale ce ne sono N altre, fin qui nessun problema.
ho tuttavia anche la necessità di escludere alcune di queste dir dal risultato finale.

ho provato in questo modo ma senza successo:

$ tar --exclude=/pattern/della/dir/da/escludere -cf file.tar /directory_principale

non va, non va nemmeno cambiando l'ordine ovvero spostando l'exclude alla fine, non va neanche aggiungendo singoli o doppi apici. ho trovato online varie soluzioni proposte ma nessuna pare funzionare.

sicuramente sono io che sto annegando nel proverbiale bicchier d'acqua ma tant'è... qualche consiglio?

grazie anticipatamente per ogni eventuale risposta.
Categorie: Forum Debianizzati

Driver NVIDIA Corporation C79 [GeForce 9200M G]

Mer, 02/07/2014 - 00:03
Ciao a tutti.
che driver installare con questa scheda video?
lspci | grep VGA
02:00.0 VGA compatible controller: NVIDIA Corporation C79 [GeForce 9200M G] (rev b1)

son su debian squeeze e ho abilitato i repo non-free lts.
con i driver open ho dei blocchi improvvisi e dei problemi di luminosità.spero si possa risolvere in quelche modo..
grazie in anticipo
Categorie: Forum Debianizzati

Re: Sostituzione GPU

Mar, 01/07/2014 - 18:30
Mmmm ragazzi sono molto confuso.
Oggi è arrivata la scheda, faccio il cambio e va tutto a buon fine.
Accendo il pc, startx, tutto ok se non che:

glxinfo | grep render
direct rendering: Yes
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.4, 128 bits)
    GL_MESA_ycbcr_texture, GL_NV_blend_square, GL_NV_conditional_render,


Non sta usando i driver corretti. La mia scheda è basata sul chip denominato PITCAIRN. Se vado a vedere nei moduli del kernel, in firmware sono correttamente elencati.

dmesg | grep -E 'drm|radeon' | grep -iE 'firmware|microcode'
[    1.685129] [drm] Loading PITCAIRN Microcode
[    1.685786] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_pfp.bin
[    1.686589] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_me.bin
[    1.687048] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_ce.bin
[    1.687962] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_rlc.bin
[    1.688349] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_mc2.bin
[    1.689521] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/PITCAIRN_smc.bin
[    1.703442] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/TAHITI_uvd.bin


Il problema è che Xorg avvisa la mancanza di glamor.
(II) LoadModule: "glamoregl"
[    12.457] (WW) Warning, couldn't open module glamoregl
[    12.457] (II) UnloadModule: "glamoregl"
[    12.457] (II) Unloading glamoregl
[    12.457] (EE) Failed to load module "glamoregl" (module does not exist, 0)


Tuttavia non sono riuscito a trovare un solo pacchetto che si chiami glamor.

Che diavolo sto sbagliando?
Non capisco. Ho provato beceramente a togliere completamente Xorg, pulire i file di configurazione e reinstallare, ma non è servito a nulla.

EDIT: sono giunto alla soluzione, credo.
Qui sembrano avere il mio stesso problema. Soluzione: ricompilarsi da sorgente: mesa, driver-ati, glamor e kernel (quest'ultimo proverò ad evitarlo).
Ora provo, poi vi dirò.

Il tutto perchè da quanto ho capito Glamor al momento su debian non è pacchettizzato.
Categorie: Forum Debianizzati

Re: HP 250 dopo upgrade 24.6 non parte

Mar, 01/07/2014 - 17:29
ma hai scaricato solo il cd1?
prova questa(dvd1) e prima di masterizzare controlla l'MD5
(ancora meglio se metti la ISO in una chiavetta...così non stai a masterizzare sempre...)
p.s. comunque l'idea di usare la stable non è malvagia....
Categorie: Forum Debianizzati

Re: Perchè esiste un repo media separato?

Mar, 01/07/2014 - 16:39
lordalbert ha scritto:senza voler entrare in polemica, ma mi sembra assurdo che una distribuzione come debian decida di abbandonare ffmpeg (so che è stato forkato in libav... ma da quanto ne so, ffmpeg è ancora vivo). Scelta dovuta al fatto che i principali sviluppatori di libav (che prima lavoravano su ffmpeg) sono i manutentori di tali pacchetti di debian e ubuntu, a quanto ho letto in giro.

Voglio dire... lasciare la scelta all'utente no?

Si presume che l'utilizzatore di debian stable abbia un minimo di conoscenza del sistema, e quindi potrebbero ben lasciare a lui la scelta di quale usare...


Non avevo dato tanta importanza a questo messaggio, ma leggendo meglio la storia è una cosa pazzesca.
Cerco di riassumere in breve. In pratica sin dal 2000 esiste FFmpeg, ottimo progetto. Nel 2011 per motivi personali o comunque banali, un paio di sviluppatori si tirano fuori dal progetto e fanno un fork di FFmpeg. Fin qui niente di strano, succede tante volte nell'open source. I problemi invece ci sono, perché:
- il nuovo progetto, libav, vuole sostituire FFmpeg e non rinomina le librerie rendendo la coesistenza dei due set di librerie impossibile;
- uno degli sviluppatori di libav è anche il manutentore di FFmpeg in Debian e Ubuntu, e come se niente fosse ha deciso di rimpiazzare FFmpeg con libav;
- nel metapacchetto che porta alla migrazione da ffmpeg a libav si fa intendere all'utente che il progetto ffmpeg è praticamente morto, quando invece è ancora vivo e ben più attivo di libav;
- libav in confronto a ffmpeg è più immaturo, mancano tante features e introduce dei cambiamenti nelle API, ed ignora completamente lo sviluppo di ffmpeg;
- ffmpeg al contrario unisce quasi giornalmente tutti i cambiamenti e le innovazioni introdotte da libav, cosicché ffmpeg avrà sempre un set maggiore di features di libav e al contempo cerca di limitare il breaking delle API.

Un progetto e un manutentore serio avrebbero dovuto creare una soluzione tale da permettere all'utente finale quale dei due progetti usare, e non scalzare il contendente facendo credere all'utente che era la cosa giusta da fare.
Questo comportamento mi pare molto immaturo e indegno per un grande progetto come Debian, e infatti in questo bug report gli utenti si lamentano: https://bugs.debian.org/cgi-bin/bugrepo ... bug=729203 (ancora devo finire di leggerlo tutto, speriamo non si tiri in mezzo la burocrazia e passino mesi per prendere una decisione apparentemente facile).

EDIT: trovata una pagina con l'interessante storia del fork (e l'esilarante gestione di libav): http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
Categorie: Forum Debianizzati