Problemi con i package FFmpeg 20081129 e X264 20081129

[phobos3576]

Segnalo che il nuovo package FFmpeg 20081129 crea seri problemi a VLC; i video mov e avi non vengono più riprodotti (si sente solo l'audio), mentre i video FLI/FLV mandano in segmentation fault il programma!

Rimettendo il vecchio FFmpeg 20080812 si risolve tutto.
Non ho provato a verificare se sia possibile risolvere anche ricompilando VLC.

Ci sono anche problemi minori con il nuovo package X264 20081129; mplayer-1.0rc2try1-x86-4sl non si avvia segnalando l'assenza della libreria /usr/lib/libx264.so.59.

In effetti, il package X264 20081129 installa una libreria /usr/lib/libx264.so.65; il problema quindi si può aggirare con un link simbolico:

Codice: Seleziona tutto

ln -s libx264.so.65 libx264.so.59

[d4z_c0nf]

Segnalo che il nuovo package FFmpeg 20081129 crea seri problemi a VLC; i video mov e avi non vengono più riprodotti (si sente solo l'audio), mentre i video FLI/FLV mandano in segmentation fault il programma!

Rimettendo il vecchio FFmpeg 20080812 si risolve tutto.
Non ho provato a verificare se sia possibile risolvere anche ricompilando VLC.

Ci sono anche problemi minori con il nuovo package X264 20081129; mplayer-1.0rc2try1-x86-4sl non si avvia segnalando l'assenza della libreria /usr/lib/libx264.so.59.

In effetti, il package X264 20081129 installa una libreria /usr/lib/libx264.so.65; il problema quindi si può aggirare con un link simbolico:

Codice: Seleziona tutto

ln -s libx264.so.65 libx264.so.59

Per esperienza phob, se ricompili vlc, risolvi.
rock

[phobos3576]

Per esperienza phob, se ricompili vlc, risolvi.
rock

Adesso provo.

Più che altro però intendevo sottolineare che il vero problema è la totale mancanza di coordinamento tra gli sviluppatori nel mondo Linux; si aggiorna una libreria e una serie di programmi smettono di funzionare!

[d4z_c0nf]

Per esperienza phob, se ricompili vlc, risolvi.
rock

Adesso provo.

Più che altro però intendevo sottolineare che il vero problema è la totale mancanza di coordinamento tra gli sviluppatori nel mondo Linux; si aggiorna una libreria e una serie di programmi smettono di funzionare!

Eh sì ti capisco.
Purtroppo è dura stare dietro a tutte le dipendenze, bisognerebbe ricompilare un tool ogni volta che una minima dipendenza si aggiorna. Soprattutto con pacchetti tipo ffmpeg e x264 che sono sempre in svn.
rock

[targzeta]

...Più che altro però intendevo sottolineare che il vero problema è la totale mancanza di coordinamento tra gli sviluppatori nel mondo Linux; si aggiorna una libreria e una serie di programmi smettono di funzionare!

Bhé, scusa, ma che pretendi? Tu compili un programma in modo che possa usare una determinata libreria condivisa. Poi aggiorni la suddetta libreria, se non si rimane sullo stesso major non vedo perchè il programma dovrebbe funzionare . Se vuoi che un programma funzioni sempre basta compilargli le librerie in maniera statica, ma quel punto non ti servono più le librerie condivise .
Il processo di sviluppo deve continuare, e anche per questo che esistono le distribuzioni, le quali forniscono una fotografia di un insieme di progetti. Tutti i programmi nella distribuzione funzionano, ma se tu decidi di fare un upgrade non puoi pretendere che i programmi continuino a funzionare ancora.
Tanto più che generalmente basta una semplice ricompilazione per far si che il proprio programma si ri-linki con la nuova libreria, a meno che le api non sono cambiate, ma se così è, coloro che seguono il programma stai tranquillo che hanno già un nuova release pronta a funzionare con le nuove api.

Io direi che va tutt'altro che male .

Spina

P.S. E' ovvio che le distro come la nostra, che non offrono tutti i programmi che vorremmo, devono essere supportate grazie anche al nostro ausilio, vedi slackbuild personali etc...etc.., ma se decidi di aggiornare una libreria (ma a volte anche un programma) devi sapere chi usa chi e chi dipende da chi. Il lavoro di PJV non è mica semplice

[phobos3576]

Prima di tutto, ho ricompilato VLC e adesso funziona anche con le nuove FFMPEG!

Thanks d4z_c0nf.

Poi, per rispondere a Spina, non intendevo assolutamente polemizzare; devi renderti conto però che con questa situazione si viene a creare il caos. Per non parlare dei niubbi che, davanti a cose del genere, se la danno a gambe e tornano a Windows.

C'è anche l'altro assurdo problema di certi programmi che vanno a cercare una particolare versione di una libreria; l'altro giorno si era parlato di K3b che va a cercare la libdvdread.so.3 e quindi non funziona con la nuova versione che installa un file libdvdread.so.4.
Adesso, stesso problema con la nuova release di MPlayer che va a cercare una particolare versione di libx264.
In entrambi i casi si risolve creando dei link simbolici.

Non ci sarebbe bisogno di questi salti mortali se K3b e MPlayer facessero riferimento a generici link simbolici a quelle librerie.
Ad esempio, è sempre presente un link simbolico libdvdread.so; se K3b andasse a cercare quel link, non costringerebbe gli utenti a ricompilare tutto ogni volta.

[targzeta]

...
Poi, per rispondere a Spina, non intendevo assolutamente polemizzare;

Nessuna polemica, davvero, scusa se ti ho dato questa impressione .

...
devi renderti conto però che con questa situazione si viene a creare il caos. Per non parlare dei niubbi che, davanti a cose del genere, se la danno a gambe e tornano a Windows.

Ecco, e qui il punto, la confusione si crea perchè noi la vogliamo creare, siamo noi che decidiamo di upgradare un programma o una libreria, e quindi siamo noi gli artefici del nostro futuro

...
C'è anche l'altro assurdo problema di certi programmi che vanno a cercare una particolare versione di una libreria; l'altro giorno si era parlato di K3b che va a cercare la libdvdread.so.3 e quindi non funziona con la nuova versione che installa un file libdvdread.so.4.
Adesso, stesso problema con la nuova release di MPlayer che va a cercare una particolare versione di libx264.
In entrambi i casi si risolve creando dei link simbolici.

Non ci sarebbe bisogno di questi salti mortali se K3b e MPlayer facessero riferimento a generici link simbolici a quelle librerie.
Ad esempio, è sempre presente un link simbolico libdvdread.so; se K3b andasse a cercare quel link, non costringerebbe gli utenti a ricompilare tutto ogni volta.

Questo è quello che ti dicevo prima, quando le librerie cambiano major chi si linka con quelle non le trovano più. Il punto è che se io sviluppo un software che usa quella specifica libreria, so come usarla finché rimane quella, nel momento in cui cambia major, allora anche io devo adattare il mio codice affinché funzioni con la nuova libreria, perchè di solito non è garantita la compatibilità. Che poi ingannando un programma questo continui a funzionare uguale non è mica garantito. Infatti a volte, anche ricompilando ti da errore, quando ad esempio le api sono cambiate.

Senza polemica, davvero, e che è l'una di notte e mi prende bene chiaccherare ,
Spina

[targzeta]

Interessante sarebbe invece uno script o programma che ti dice:"occhi che se aggiorni questo pacchetto, è probabile che devi aggiornare anche questo e questo e questo pacchetto". Ne sapete niente? Altrimenti lo possiamo fare....se vi va

Spina

[d4z_c0nf]

Interessante sarebbe invece uno script o programma che ti dice:"occhi che se aggiorni questo pacchetto, è probabile che devi aggiornare anche questo e questo e questo pacchetto". Ne sapete niente? Altrimenti lo possiamo fare....se vi va

Spina

Cioè intendi uno script magari nel doinst.sh, che faccia un controllo su quali altri tool sulla tua macchina utilizzano una lib condivisa, "obsoleta" del pacchetto in questione?
rock

[targzeta]

Stamattina mi sono svegliato con questo pensiero in testa. Risolvere il problema delle dipendenze una volta per tutte! Si sa che altre distribuzioni risolvono le dipendenze, ma che vuol dire di preciso "risolvere le dipendenze"?
Putroppo o per fortuna conosco solo la Slackware, e quindi non ho idea di cosa facciano le altre distribuzioni. L'idea è fare un programma che risponda a tutte le domande che uno si può porre circa i suoi pacchetti, ad esempio:

• Il pacchetto X da quali pacchetti dipende?
• Quali pacchetti dipendono dal pacchetto X?
• Se tolgo il pacchetto X quali pacchetti risultano inusabili (caso particolare del punto precedente)?
• Se aggiorno il pacchetto X quali pacchetti dovrei aggiornare (anche questo è un caso particolare del punto 2)?
• Il programma X in quale pacchetto si trova?
• Il programma X da quali pacchetti dipende?
• Il programma X da quali librerie o binari dipende?

A tutte queste domanda si può rispondere con uno script ad-hoc che si mette a scandire la directory /var/log/package, più chiamate di ldd e di strace. L'idea invece è di creare un database con tutte queste informazioni già pronte, che poi viene interrogato dall'utente.

Se il software è ben scritto è possibile far si che tutte le distribuzioni lo possano usare per gestire le proprie dipendenze.
Pensando alla Slackware mi immagino delle chiamate all'interno degli script installpgk, upgradepkg, e removepkg per mantenere aggiornato il database.

Però, sempre stamani pensavo che per fare un software così, mi ci vorrà molto tempo

Spina

[d4z_c0nf]

Stamattina mi sono svegliato con questo pensiero in testa. Risolvere il problema delle dipendenze una volta per tutte! Si sa che altre distribuzioni risolvono le dipendenze, ma che vuol dire di preciso "risolvere le dipendenze"?
Putroppo o per fortuna conosco solo la Slackware, e quindi non ho idea di cosa facciano le altre distribuzioni. L'idea è fare un programma che risponda a tutte le domande che uno si può porre circa i suoi pacchetti, ad esempio:

• Il pacchetto X da quali pacchetti dipende?
• Quali pacchetti dipendono dal pacchetto X?
• Se tolgo il pacchetto X quali pacchetti risultano inusabili (caso particolare del punto precedente)?
• Se aggiorno il pacchetto X quali pacchetti dovrei aggiornare (anche questo è un caso particolare del punto 2)?
• Il programma X in quale pacchetto si trova?
• Il programma X da quali pacchetti dipende?
• Il programma X da quali librerie o binari dipende?

A tutte queste domanda si può rispondere con uno script ad-hoc che si mette a scandire la directory /var/log/package, più chiamate di ldd e di strace. L'idea invece è di creare un database con tutte queste informazioni già pronte, che poi viene interrogato dall'utente.

Se il software è ben scritto è possibile far si che tutte le distribuzioni lo possano usare per gestire le proprie dipendenze.
Pensando alla Slackware mi immagino delle chiamate all'interno degli script installpgk, upgradepkg, e removepkg per mantenere aggiornato il database.

Però, sempre stamani pensavo che per fare un software così, mi ci vorrà molto tempo

Spina

Spina, ma tracepkg, non fa già una cosa del genere?
rock

[fAu]

Interessante sarebbe invece uno script o programma che ti dice:"occhi che se aggiorni questo pacchetto, è probabile che devi aggiornare anche questo e questo e questo pacchetto". Ne sapete niente? Altrimenti lo possiamo fare....se vi va

Spina

Cioè intendi uno script magari nel doinst.sh, che faccia un controllo su quali altri tool sulla tua macchina utilizzano una lib condivisa, "obsoleta" del pacchetto in questione?
rock

non solo sulla tua macchina ma che controlli anche nel repository a cui si attinge con slapt-get ... come ha scritto poi anche spina sicuramente e' una cosa complessa da realizzare ma se funziona hai un sistema di upgrade a prova di qualsiasi user.

[targzeta]

...
Spina, ma tracepkg, non fa già una cosa del genere?
rock

Non so. non lo uso. E' un programma o uno script? E' pensato lavorare su più distribuzioni o solo per Slackware?

Ci sarebbe un altra domanda da fare al database

• Tutte le librerie (e quindi i pacchetti) da cui dipende un pacchetto X (o un programma X, o una libreria X), sono installate?

Alla domanda, per collegarmi a fAu,

• Se manca qualcosa, dove la trovo?

invece non credo che debba essere il programma a dare una risposta. Questa risposta dovrebbe essere data da un sofware esterno che usa il programma.

Spina

[d4z_c0nf]

...
Spina, ma tracepkg, non fa già una cosa del genere?
rock

Non so. non lo uso. E' un programma o uno script? E' pensato lavorare su più distribuzioni o solo per Slackware?
Spina

Collezione di script. L'ha fatto absinthe.
http://www.slacky.eu/index.php?option=c ... &Itemid=65
rock

[targzeta]

...Collezione di script. L'ha fatto absinthe.
http://www.slacky.eu/index.php?option=c ... &Itemid=65
rock

E' interessante, ma non è quello che intendo io. Se vedi un mio post più in alto, spiegavo che tutto si può fare con degli script, ma non è la stessa cosa.
Inoltre, da quello che ho letto nell'intro, lo script sembra non tener presente i programmi front-end di altri programmi. Tramite ldd non si può capire se un programma necessita di un altro eseguibile.
Il progetto dovrebbe essere ambizioso a tal punto da spingere anche PJV ad includere chiamate al software negli script di gestione dei pacchetti slackware. Solo a quel punto si avrebbe un sistema di gestione di dipendenze veramente carino.

Il punto è sempre lo stesso, il gioco vale la candela? Cioè, io posso anche iniziare a scrivere codice, ma serve veramente ?

Spina