Re: libmp3lame0 ed audio
Ciao Gabriele, grazie per la risposta. On 2022-12-05 17:52, Gabriele Stilli wrote: Il 05/12/22 10:05, Luca Sighinolfi ha scritto: qualche giorno fa ho riavviato il PC dopo un po' di tempo (circa 90 gg). Debian testing aggiornata quotidianamente, kernel 6.0.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Secondo me non hai esattamente testing… Alla fine mi sono deciso a disinstallare e reinstallare un po' di roba e mi sembra che sia andato tutto a buon fine. Durante la reinstallazione libavcodec57 non è stato più installato. Ho visto che era richiesto da ffmpeg, ma, come dicevo, reinstallando è stato eliminato definitivamente. In realtà il sistema mi dice che libmp3lame0 è all'ultima versione, ma dice anche che libavcodec57 chiede una versione maggiore di 3.99 (ed effettivamente la 3.100 è maggiore di 3.99), ma non gli piace libavcodec57 si è visto per l'ultima volta in stretch, che è oldoldstable, altro che testing :-) Già, questo è vero. Sarebbe interessante capire come mai il sistema si ostinava a tenere un pacchetto così vecchio... Io farei un controllo su cosa veramente gira su quella macchina. Ovvero, come potrei fare? libmp3lame0 is already the newest version (3.100-6). You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: libavcodec57 : Depends: libmp3lame0 (>= 1:3.99.0) but 3.100-6 is to be installed Per la cronaca, il problema con la dipendenza si chiama "epoch": la versione di libmp3lame0 da cui dipenderebbe libavcodec57 è 1:3.99.0 (o successive), con un epoch di "1:", mentre la versione che hai tu è 3.100, senza epoch. Un numero di versione con epoch è sempre più recente di un numero senza epoch e un numero di versione con epoch maggiore è sempre più recente di uno con epoch minore. Quindi, per Debian, 1:3.99.0 è più recente di 3.100, perché il primo ha un epoch, il secondo no. Per questo apt protesta: secondo apt, la dipendenza non è soddisfatta. Però la cosa è comunque sospetta, perché proprio dalla pagina di libavcodec57 su packages debian.org si nota che la dipendenza è su libmp3lame0 senza specificare numeri di versione: https://packages.debian.org/stretch/libavcodec57 Ho capito il discorso dell'epoch, che non conoscevo, interessante. Tuttavia se vado a vedere il sito di libmp3lame0 non c'è traccia di epoch. Quindi non capisco da dove sia nato il "1:". https://packages.debian.org/search?keywords=libmp3lame0=names=all=all Mi viene quindi il dubbio che quel pacchetto venga da un altro archivio (ad esempio, tiro a caso, deb-multimedia.org). Dai un'occhiata al contenuto di /etc/apt/sources.list e della directory /etc/apt/sources.list.d ed eventualmente agisci di conseguenza. Tempo fa avevo messo in source.list una riga che riguardava la stable (quindi avevo stable, testing, unstable). Avevo poi anche aggiunto ad apt la questione della priorità in modo che fosse preferita testing. Al momento della reinstallazione, mi sono accorto che per mplayer, che non è per ora presente in testing, apt voleva installare una vecchia versione di stable, invece della unstable (in cui mplayer è presente). Probabilmente avevo assegnato la priorità a stable rispetto ad unstable ed è probabile che ciò mi tenesse bloccato libavcodec57. Adesso ho eliminato la riga della stable nel source.list, e mi ha installato mplayer correttamente (unstable). Se un domani mi servirà nuovamente il ramo stable, vedrò di sistemare le priorità fra stable ed unstable. Gabriele :-) Grazie Ciao -- Luca Sighinolfi
Re: Uefi+mdadm
On Mon, Dec 05, 2022 at 07:38:00PM +0100, Diego Zuccato wrote: > Il 05/12/2022 18:09, Marco Ciampa ha scritto: > > Mah io sono abbastanza scettico sui controller hw. Se sono del tipo > > "fake" ovvero software, ok linux li supporta per cui puoi far funzionare > > il raid anche se non hai il controller. > Questo non mi è mai riuscito. > Comunque normalmente è un sistema che uso quando ho parecchia scorta di ctrl > :) Perché devi installare il pacchetto dmraid ... > > > Questo trattasi di un'estensione > > del bios che serve a fare il sync da bios appunto ma ha un sacco di > > limiti: principalmente può solo trattare dischi interi e non partizioni > > quindi combinazioni tipo RAID1 per il boot e RAID5 per il resto sono > > impossibili. > Esatto. Ma tutte le controller che conosco trattano solo dischi interi. > > > I controller RAID hardware _veri_ costano un sacco (spesso > > più di una scheda madre), > Dipende dalla mobo. Comunque molto spesso con 200€ prendi una ctrl RAID > decente. Poi chiaramente se vuoi che supporti RAID6 su batterie di SAS > expander allora il prezzo sale velocemente... > > > non sono esenti da problemi (tutto sommato il > > RAID software di linux è più affidabile) e vogliono necessariamente > > batteria tampone o supercapacitori con memoria flash e driver appositi > > nel kernel che sono giocoforza meno affidabili come driver dei driver > > standard per questioni di meri numeri. > Scordi quello che IMO è il difetto più grande delle ctrl RAID HW: se la > controller rilascia il fumo magico, troppo spesso non hai altro modo di > recuperare i dati dai dischi se non installando un'altra controller > identica. E talvolta neppure così :( Non chiedermi come lo so... :( > Auguri se il server è vecchio e la controller oramai fuori produzione da > anni... Esatto > > Insomma il gioco non vale la > > candela e infatti oramai si tende a usarli sempre meno. > Ni. Ho ordinato a febbraio un server di storage con HBA (in pratica una > scheda RAID senza la funzione RAID) e mi è arrivato la settimana scorsa. Se > avessi chiesto la controller RAID, sarebbe arrivato ad aprile... Per lo meno > spero che mi abbiano messo la HBA... Non sono ancora riuscito a collegarlo. O forse ti è arrivato perché ne hanno pieni i magazzini e nessuno li compera più? Chissà... poi con quello che costa la tecnologia SAN... va beh speculazioni, sono d'accordo con te praticamente sempre... -- Amike, Marco Ciampa
Re: Uefi+mdadm
Il 05/12/2022 18:09, Marco Ciampa ha scritto: Mah io sono abbastanza scettico sui controller hw. Se sono del tipo "fake" ovvero software, ok linux li supporta per cui puoi far funzionare il raid anche se non hai il controller. Questo non mi è mai riuscito. Comunque normalmente è un sistema che uso quando ho parecchia scorta di ctrl :) Questo trattasi di un'estensione del bios che serve a fare il sync da bios appunto ma ha un sacco di limiti: principalmente può solo trattare dischi interi e non partizioni quindi combinazioni tipo RAID1 per il boot e RAID5 per il resto sono impossibili. Esatto. Ma tutte le controller che conosco trattano solo dischi interi. I controller RAID hardware _veri_ costano un sacco (spesso più di una scheda madre), Dipende dalla mobo. Comunque molto spesso con 200€ prendi una ctrl RAID decente. Poi chiaramente se vuoi che supporti RAID6 su batterie di SAS expander allora il prezzo sale velocemente... non sono esenti da problemi (tutto sommato il RAID software di linux è più affidabile) e vogliono necessariamente batteria tampone o supercapacitori con memoria flash e driver appositi nel kernel che sono giocoforza meno affidabili come driver dei driver standard per questioni di meri numeri. Scordi quello che IMO è il difetto più grande delle ctrl RAID HW: se la controller rilascia il fumo magico, troppo spesso non hai altro modo di recuperare i dati dai dischi se non installando un'altra controller identica. E talvolta neppure così :( Non chiedermi come lo so... :( Auguri se il server è vecchio e la controller oramai fuori produzione da anni... Insomma il gioco non vale la candela e infatti oramai si tende a usarli sempre meno. Ni. Ho ordinato a febbraio un server di storage con HBA (in pratica una scheda RAID senza la funzione RAID) e mi è arrivato la settimana scorsa. Se avessi chiesto la controller RAID, sarebbe arrivato ad aprile... Per lo meno spero che mi abbiano messo la HBA... Non sono ancora riuscito a collegarlo. -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: libmp3lame0 ed audio
Il 05/12/22 10:05, Luca Sighinolfi ha scritto: > qualche giorno fa ho riavviato il PC dopo un po' di tempo (circa 90 gg). > > Debian testing aggiornata quotidianamente, > kernel 6.0.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Secondo me non hai esattamente testing… > In realtà il sistema mi dice che libmp3lame0 è all'ultima versione, ma > dice anche che libavcodec57 chiede una versione maggiore di 3.99 (ed > effettivamente la 3.100 è maggiore di 3.99), ma non gli piace libavcodec57 si è visto per l'ultima volta in stretch, che è oldoldstable, altro che testing :-) Io farei un controllo su cosa veramente gira su quella macchina. > libmp3lame0 is already the newest version (3.100-6). > You might want to run 'apt --fix-broken install' to correct these. > The following packages have unmet dependencies: >libavcodec57 : Depends: libmp3lame0 (>= 1:3.99.0) but 3.100-6 >is to be installed Per la cronaca, il problema con la dipendenza si chiama "epoch": la versione di libmp3lame0 da cui dipenderebbe libavcodec57 è 1:3.99.0 (o successive), con un epoch di "1:", mentre la versione che hai tu è 3.100, senza epoch. Un numero di versione con epoch è sempre più recente di un numero senza epoch e un numero di versione con epoch maggiore è sempre più recente di uno con epoch minore. Quindi, per Debian, 1:3.99.0 è più recente di 3.100, perché il primo ha un epoch, il secondo no. Per questo apt protesta: secondo apt, la dipendenza non è soddisfatta. Però la cosa è comunque sospetta, perché proprio dalla pagina di libavcodec57 su packages debian.org si nota che la dipendenza è su libmp3lame0 senza specificare numeri di versione: https://packages.debian.org/stretch/libavcodec57 Mi viene quindi il dubbio che quel pacchetto venga da un altro archivio (ad esempio, tiro a caso, deb-multimedia.org). Dai un'occhiata al contenuto di /etc/apt/sources.list e della directory /etc/apt/sources.list.d ed eventualmente agisci di conseguenza. Gabriele :-)
Re: Uefi+mdadm
On Mon, Dec 05, 2022 at 09:30:30AM +0100, Diego Zuccato wrote: > Il 04/12/2022 21:27, Marco Ciampa ha scritto: > > Il metodo più semplice è usare una controllerina con RAID1 HW (ne avevo > viste anche che si spacciavano direttamente per un disco, praticamente "in > line" sul cavo SATA), che sia il più trasparente possibile sia per il BIOS > che poi per il SO. > Oltretutto molti firmware recenti su motherboard di classe server già > prevedono il RAID1. Ovviamente però sempre a livello di disco intero. Mah io sono abbastanza scettico sui controller hw. Se sono del tipo "fake" ovvero software, ok linux li supporta per cui puoi far funzionare il raid anche se non hai il controller. Questo trattasi di un'estensione del bios che serve a fare il sync da bios appunto ma ha un sacco di limiti: principalmente può solo trattare dischi interi e non partizioni quindi combinazioni tipo RAID1 per il boot e RAID5 per il resto sono impossibili. I controller RAID hardware _veri_ costano un sacco (spesso più di una scheda madre), non sono esenti da problemi (tutto sommato il RAID software di linux è più affidabile) e vogliono necessariamente batteria tampone o supercapacitori con memoria flash e driver appositi nel kernel che sono giocoforza meno affidabili come driver dei driver standard per questioni di meri numeri. Insomma il gioco non vale la candela e infatti oramai si tende a usarli sempre meno. > > in pratica devi fare un RAID1 con metadata (1.0) che non "confonde" il > > BIOS e riconosce il RAID come FAT32 ed il gioco è fatto... > > E questo è stato anche il mio fallback per server blade, dove > praticamente non sarebbe entrata neanche una zanzara e quindi la soluzione > con controllerina extra era inapplicabile. > Questa soluzione permette anche "giochi" più complessi (p.e. 1G di RAID1 per > UEFI sui primi 2 dischi, il resto in RAID5 su 4 dischi, e nello spazio > iniziale degli altri 2 dischi due partizioni di swap da 1G ognuna). yes -- Amike, Marco Ciampa
Re: X220 Touchpad su Debian 11
Ciao , sì ho provato ma purtroppo dando il comando: sudo dmesg | grep -i serio ottengo: psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd002a3/0x940300/0x123800/0x0, board id: 1611, fw id: 1099905 e il comportamento del clickpad rimane lo stesso. Inoltre, sempre per quanto riguarda il clickpad, riscontro un problema sul tasto destro, che viene letto come se fosse il sinistro. Ciao e grazie Emanuele > EePo ha scritto: > > > ho acquistato un Thinkpad X220 sul quale ho > > installato Debian 11. Funziona tutto perfettamente > > tranne il > > touchpad(clickpad) > > hai già provato a fare quanto riportato sul wiki di > Debian[¹]? > > Ciao > Davide > > [¹] > https://wiki.debian.org/InstallingDebianOn/Thinkpad/X220 > > -- > La mia privacy non è affar tuo > https://noyb.eu/it >
Re: Uefi+mdadm
Il 04/12/2022 21:27, Marco Ciampa ha scritto: Il metodo più semplice è usare una controllerina con RAID1 HW (ne avevo viste anche che si spacciavano direttamente per un disco, praticamente "in line" sul cavo SATA), che sia il più trasparente possibile sia per il BIOS che poi per il SO. Oltretutto molti firmware recenti su motherboard di classe server già prevedono il RAID1. Ovviamente però sempre a livello di disco intero. in pratica devi fare un RAID1 con metadata (1.0) che non "confonde" il BIOS e riconosce il RAID come FAT32 ed il gioco è fatto...E questo è stato anche il mio fallback per server blade, dove praticamente non sarebbe entrata neanche una zanzara e quindi la soluzione con controllerina extra era inapplicabile. Questa soluzione permette anche "giochi" più complessi (p.e. 1G di RAID1 per UEFI sui primi 2 dischi, il resto in RAID5 su 4 dischi, e nello spazio iniziale degli altri 2 dischi due partizioni di swap da 1G ognuna). -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Re: libmp3lame0 ed audio
On 2022-12-05 10:07, Davide Prina wrote: Luca Sighinolfi ha scritto: qualche giorno fa ho riavviato il PC dopo un po' di tempo (circa 90 gg). Debian testing aggiornata quotidianamente, ma come fai ad aggiornarla quotidianamente e non riavviare da 90 giorni? Quando arriva una nuova versione di Linux sei costretto in qualche modo a riavviare, altrimenti alcune cose iniziano a non funzionare più correttamente... e negli ultimi 90 giorni ne sono arrivate parecchie quindi avevi in esecuzione Linux 5.19 o precedente... Si corretto, avevo un kernel precedente. Al riavvio l'audio non funzionava più. Purtroppo non mi sono segnato l'errore, ma aveva a che fare con un symbol contenuto nel pacchetto libmp3lame0. Leggendo varie cose in rete, ed un po' a tentativi, ho aggiornato da 3.99 a 3.100-6 il pacchetto libmp3lame0 manualmente con dpkg scaricando a mano libmp3lame0. ma da dove lo hai scaricato? Sarebbe meglio rimuoverlo con --purge e reinstallarlo dai repository ufficiali. Ho preso il .deb dal sito di Debian e poi installato con dpkg. Se lo rimuovevo con --purge, mi toglieva un sacco di roba poi tutta da reinstallare. mi sembra di aver capito che libmp3lame0 ha un bug per cui la 3.99 viene vista come più recente della 3.100 e quindi ora aptitude mi vuole disinstallare una marea di roba. ma non è che il problema è di aptitude hai provato con apt? Ho provato sia con apt che con aptitude. Propongono entrambi soluzioni analoghe. In realtà il sistema mi dice che libmp3lame0 è all'ultima versione, ma dice anche che libavcodec57 chiede una versione maggiore di 3.99 (ed effettivamente la 3.100 è maggiore di 3.99), ma non gli piace io ho libmp3lame0, ma libavcodec57 non è installato. Posso provare a togliere e vedere che succede... Se chiedo di rimuovere libavcondec57 mi vuole togliere anche ffmpeg che uso attivamente... Anch'io sono su una testing. Se eseguo: $ apt apt policy libavcodec57 libavcodec57: Installato: (nessuno) Candidato: (nessuno) Tabella versione: policy libavcodec57 libavcodec57: Installato: (nessuno) Candidato: (nessuno) Tabella versione: libmp3lame0 is already the newest version (3.100-6). You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: libavcodec57 : Depends: libmp3lame0 (>= 1:3.99.0) but 3.100-6 is to be installed Se faccio --fix-broken mi vuole disinstallare mezzo mondo inclusi mencoder, mpv, mplayer, ffmpeg, etc... io segnalerei come bug... però forse il bug è su libavcodec57... Poi proverei a rimuovere libavcodec57 che tanto è un pacchetto virtuale, puoi sempre installare a mano quello che ti serve. Per l'audio che pacchetti usati? io ho lasciato fare al sistema... non ho fatto nulla di intenzionale per installare o meno dei pacchetti per l'audio Forse il mio problema è che il mio sistema è ancora quello della prima installazione che risale a più di 15 anni fa. Ho pensato più volte a reinstallare, ma non l'ho mai fatto alla fine per paura di perdere alcune configurazioni. Il fatto che l'installazione orginale sia così vecchia, può essere un problema? Ciao Davide -- La mia privacy non è affar tuo https://noyb.eu/it Grazie Ciao -- Luca Sighinolfi
contrllo versione Linux in esecuzione
Ciao, su una macchina non mia che ogni tanto passo ad aggiornare ho trovato questa cosa strana: gli aggiornamenti li faceva senza problema, ma non aggiornava la lista dei Linux da avviare con grub. In effetti eseguiva sempre una vecchia versione di Linux... La macchina è una Debian stable Il problema era che non c'era installato grub-pc Inoltre facendogli gli aggiornamenti velocemente c'erano tanti pacchetti in stato rc (rimossi, ma con ancora i file di configurazione presenti). per rimuoverli completamente ho eseguito qualcosa del tipo # apt remove --purge $(dpkg -l | grep ^rc | cut -d ' ' -f 3) eliminando grub2 mi ha detto che se avessi continuato il sistema non sarebbe più stato avviabile... e da qui ho scoperto la problematica Volevo chiedere se potete verificare se qualcun altro ha lo stesso problema per vedere la versione di Linux in esecuzione: $ uname -r Se si è installato apt-show-versions, altrimenti va installato # apt install apt-show-versions in ogni caso aggiornare la cache # apt-show-versions -i verificare se il seguente comando $ apt-show-versions linux-image-$(uname -r) riporta il pacchetto come: installed: No available version in archive in questo caso potreste avere lo stesso problema. Se ci sono anche altri con lo stesso problema si può aprire un bug report per segnalare il problema, probabilmente su grub2 che non ha installato grup-pc per qualche motivo. Ciao Davide -- La mia privacy non è affar tuo https://noyb.eu/it
Re: Uefi+mdadm
Il 04/12/2022 21:31, Marco Ciampa ha scritto: On Sun, Dec 04, 2022 at 08:44:46PM +0100,fran...@modula.net wrote: Il 04/12/2022 20:40, Marco Ciampa ha scritto: On Sun, Dec 04, 2022 at 07:53:51PM +0100,fran...@modula.net wrote: Salve, oggi mi sono avventurato nella installazione di un Debian 11 con Uefi e raid mdadm. mdadm e Uefi non sono compatibili e quindi la partizione ESP non può stare in una partizione raid. Oibo! Da dove ti viene questa convinzione? Io ho installato poco tempo fa un RAID software su UEFI... Ho trovato questo: https://wiki.debian.org/UEFI#RAID_for_the_EFI_System_Partition eheheh in effetti due righe di rsync come pensavo risolvono ma come ti ho detto basta imbrogliare il bios e fargli credere che il RAID sia una semplice partizione FAT32 e il gioco è fatto. I due workaround, quello con rsync e quello con l'"imbroglio" del bios li avevo visti, anche se non provati. Ho un approccio molto conservativo nelle installazioni: se una caratteristica non è supportata cerco di non farmene carico. Comunque entrambe le soluzioni sono abbastanza semplici, anche se quella con l' "imbroglio" mi sembra più elegante perché non prevede codice aggiuntivo. Quella suggerita da Pivul: "ad ogni aggiornamento di grub manualmente eseguo: umount /boot/efi && mount /dev/sdx1 /boot/efi && grub-install && umount /boot/efi && mount -a dove /dev/sdx1 è la partizione efi che non viene referenziata da /etc/fsta" mi sembra meno robusta perché comporta di ricordarsi di fare alcune operazioni a mano. Il problema che vedo è che il trio "mdadm"+"uefi"+"grub" non è ben implementato nell'installer e per questo chiedevo se qualcuno sa se la caratteristica è all'attenzione di uno dei Team Debian. Finché le macchine arrivano con l'opzione Bios va bene, ma non sarà così per sempre. Credo che alcune schede già arrivino con il solo Uefi. Luciano -- Questa email è stata esaminata alla ricerca di virus dal software antivirus Avast. www.avast.com
Re: libmp3lame0 ed audio
Luca Sighinolfi ha scritto: > qualche giorno fa ho riavviato il PC dopo un po' di tempo (circa 90 gg). > > Debian testing aggiornata quotidianamente, ma come fai ad aggiornarla quotidianamente e non riavviare da 90 giorni? Quando arriva una nuova versione di Linux sei costretto in qualche modo a riavviare, altrimenti alcune cose iniziano a non funzionare più correttamente... e negli ultimi 90 giorni ne sono arrivate parecchie quindi avevi in esecuzione Linux 5.19 o precedente... > Al riavvio l'audio non funzionava più. > Purtroppo non mi sono segnato > l'errore, ma aveva a che fare con un symbol contenuto nel pacchetto > libmp3lame0. > Leggendo varie cose in rete, ed un po' a tentativi, ho aggiornato da > 3.99 a 3.100-6 il pacchetto libmp3lame0 manualmente con dpkg scaricando > a mano libmp3lame0. ma da dove lo hai scaricato? Sarebbe meglio rimuoverlo con --purge e reinstallarlo dai repository ufficiali. > mi sembra di aver capito che libmp3lame0 ha > un bug per cui la 3.99 viene vista come più recente della 3.100 e > quindi ora aptitude mi vuole disinstallare una marea di roba. ma non è che il problema è di aptitude hai provato con apt? > In realtà il sistema mi dice che libmp3lame0 è all'ultima versione, ma > dice anche che libavcodec57 chiede una versione maggiore di 3.99 (ed > effettivamente la 3.100 è maggiore di 3.99), ma non gli piace io ho libmp3lame0, ma libavcodec57 non è installato. Anch'io sono su una testing. Se eseguo: $ apt apt policy libavcodec57 libavcodec57: Installato: (nessuno) Candidato: (nessuno) Tabella versione: policy libavcodec57 libavcodec57: Installato: (nessuno) Candidato: (nessuno) Tabella versione: > libmp3lame0 is already the newest version (3.100-6). > You might want to run 'apt --fix-broken install' to correct these. > The following packages have unmet dependencies: >libavcodec57 : Depends: libmp3lame0 (>= 1:3.99.0) but 3.100-6 >is to be installed > > Se faccio --fix-broken mi vuole disinstallare mezzo mondo inclusi > mencoder, mpv, mplayer, ffmpeg, etc... io segnalerei come bug... però forse il bug è su libavcodec57... Poi proverei a rimuovere libavcodec57 che tanto è un pacchetto virtuale, puoi sempre installare a mano quello che ti serve. > Per l'audio che pacchetti usati? io ho lasciato fare al sistema... non ho fatto nulla di intenzionale per installare o meno dei pacchetti per l'audio Ciao Davide -- La mia privacy non è affar tuo https://noyb.eu/it
Re: X220 Touchpad su Debian 11
EePo ha scritto: > ho acquistato un Thinkpad X220 sul quale ho > installato Debian 11. Funziona tutto perfettamente tranne il > touchpad(clickpad) hai già provato a fare quanto riportato sul wiki di Debian[¹]? Ciao Davide [¹] https://wiki.debian.org/InstallingDebianOn/Thinkpad/X220 -- La mia privacy non è affar tuo https://noyb.eu/it
libmp3lame0 ed audio
Buongiorno a tutti, qualche giorno fa ho riavviato il PC dopo un po' di tempo (circa 90 gg). Debian testing aggiornata quotidianamente, kernel 6.0.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Al riavvio l'audio non funzionava più. Purtroppo non mi sono segnato l'errore, ma aveva a che fare con un symbol contenuto nel pacchetto libmp3lame0. Leggendo varie cose in rete, ed un po' a tentativi, ho aggiornato da 3.99 a 3.100-6 il pacchetto libmp3lame0 manualmente con dpkg scaricando a mano libmp3lame0. Questo ha risolto in parte il problema audio (anche se è monocanale, ma devo investigare meglio). E fin qui quasi tutto bene se non che mi sembra di aver capito che libmp3lame0 ha un bug per cui la 3.99 viene vista come più recente della 3.100 e quindi ora aptitude mi vuole disinstallare una marea di roba. https://packages.debian.org/search?keywords=libmp3lame0 In realtà il sistema mi dice che libmp3lame0 è all'ultima versione, ma dice anche che libavcodec57 chiede una versione maggiore di 3.99 (ed effettivamente la 3.100 è maggiore di 3.99), ma non gli piace libmp3lame0 is already the newest version (3.100-6). You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: libavcodec57 : Depends: libmp3lame0 (>= 1:3.99.0) but 3.100-6 is to be installed Se faccio --fix-broken mi vuole disinstallare mezzo mondo inclusi mencoder, mpv, mplayer, ffmpeg, etc... Qualcuno ha avuto problemi simili? Per l'audio che pacchetti usati? Avete installato anche libmp3lame0? Grazie Ciao -- Luca Sighinolfi Imparerai più nei boschi che nei libri. San Bernardo di Chiaravalle
