Gentoo: Installazione PC Server (HQPlayer, LMS ) e PC Player (NAA, Mpd, Squeezelite-R2)

[marcoc1712]

La cosa é inisziata da queto post http://www.nexthardware.com/forum/pc...tml#post964461
rileggilo!!!
(in realtá é dall´inizio che cerchi di portarla su sta roba della ebuild...non hai mai parlato di altro)

Hai estrapolato una parte di una frase dal contesto in modo errato... e hai portato su una discussione che non interessa in questa contesto...e continui....
hai iniziato a parlare di script sbagliati, sviste ecc...e ti ho dimostrato che non sono errori ma scelte...



Ho detto che abbiamo quella ebuild e usiamo quella (che é fatta molto bene!!! e fa quello che deve fare, nessuno sostiene che faccia suonare meglio squeezelite ma che lo integra come si deve nel sistema si, file di avvio, servici, file di configurazione, utente specifico e non root come il binario ecc)...ne avessimo un´altra fatta da te(e magari messa sul tuo github..sarebbe piú facile installarla) la useremo....

Per le prove hai tutti gli elementi...FALLE!!!

Il titolo del tread è gentoo+squeezelite+altro

No è "squeezelite su gentoo..qual è la scelta migliore?"

e chiudo anche io la discussione.

Mah,mi pare che il 'succo' di quel post sia quanto sono belli gli USE e meno importanti i CFLAGS (?), che sono istruzioni dichiarative usate dall'ebuild, di cosa altro avrei dovuto parlare?

Quindi parla di binari scattanti ed io credo che l'unico modo per produrre un binario sia la compilazione ed il successivo link, che nel nostro caso vengono realizzati da emake comandato dal makefile patchato dall'ebuild per collegarlo al meccanismo delle USE, in alternativa a quello nativo ed universale di squeezelite. Ancora, di cosa avrei dovuto parlare?

Finche non capisci (o rifiuti di considerare) e confondi la differenza tra patch che modifica i sorgenti, makefile che guida la compilazione ed ebuild che gestisce il tutto coordinando l'installazione, non potrai capire perchè insisto su alcune cose rispetto ad altre, ma - purtroppo - , la natura delle cose non cambia solo perchè non ti piace o non la capisci.

Io non contesto quell'ebuild se non per il fatto che applica quella specifca patch ai sorgenti, che IN SE è inutile, NON l'eBUILD, LA PATCH!!!!

Dichiarare una dipendenza inutile (pulse audio), io ho interpretato fosse una svista e così me la spiego, se fosse voluta sarebbe una c...ta! tanto varrebbe indicare la dipendenza verso kodi o open office, per citare due pacchetti a caso, ma metti quello che vuoi, non cambia.

A dimostrazione di come le USE siano solo uno strumento, che puoi utilizzare per mantenere il sistema più snello, ma anche provocare inutili appesantimenti dichiarando dipendenze inesistenti ed inutili. Tutto sta nel sapere COSA si vuole fare, quindi nel padroneggiare gli strumenti per farlo, applicando quelli corretti caso per caso in funzione della circostanze.

Però basta, se non vuoi capire, non servirà l'ennesima ripetizione.

Mi trovo al 100% in sintonia con Giovanni, per questo ho proposto una 'scaletta' di prove tesa a capire cosa rende squeezelite + gentoo (questo propone ed io lo seguo, altro non mi interessa) meglio di altre configurazioni.

In questo senso è indubbio che le variabili in gioco sono:

1. sorgenti di squeezelite (patch si, patch no)
2. parametri di compilazione (makefile ed opzioni)
3. sistema target (preconfigurato / taylor made) ipotizzando la stessa architettura di riferimento
4. architettura di riferimento

Propongo di verificarli e smarcarli nell'ordine.

Non capisco cosa ci sia di sbagliato in ciò, tu cosa proponi in altrernativa?

[antonellocaroli]

Mah,mi pare che il 'succo' di quel post sia quanto sono belli gli USE e meno importanti i CFLAGS (?), che sono istruzioni dichiarative usate dall'ebuild, di cosa altro avrei dovuto parlare?

Quindi parla di binari scattanti ed io credo che l'unico modo per produrre un binario sia la compilazione ed il successivo link, che nel nostro caso vengono realizzati da emake comandato dal makefile patchato dall'ebuild per collegarlo al meccanismo delle USE, in alternativa a quello nativo ed universale di squeezelite. Ancora, di cosa avrei dovuto parlare?

Finche non capisci (o rifiuti di considerare) e confondi la differenza tra patch che modifica i sorgenti, makefile che guida la compilazione ed ebuild che gestisce il tutto coordinando l'installazione, non potrai capire perchè insisto su alcune cose rispetto ad altre, ma - purtroppo - , la natura delle cose non cambia solo perchè non ti piace o non la capisci.

Io non contesto quell'ebuild se non per il fatto che applica quella specifca patch ai sorgenti, che IN SE è inutile, NON l'eBUILD, LA PATCH!!!!

Dichiarare una dipendenza inutile (pulse audio), io ho interpretato fosse una svista e così me la spiego, se fosse voluta sarebbe una c...ta! tanto varrebbe indicare la dipendenza verso kodi o open office, per citare due pacchetti a caso, ma metti quello che vuoi, non cambia.

A dimostrazione di come le USE siano solo uno strumento, che puoi utilizzare per mantenere il sistema più snello, ma anche provocare inutili appesantimenti dichiarando dipendenze inesistenti ed inutili. Tutto sta nel sapere COSA si vuole fare, quindi nel padroneggiare gli strumenti per farlo, applicando quelli corretti caso per caso in funzione della circostanze.

Però basta, se non vuoi capire, non servirà l'ennesima ripetizione.

Mi trovo al 100% in sintonia con Giovanni, per questo ho proposto una 'scaletta' di prove tesa a capire cosa rende squeezelite + gentoo (questo propone ed io lo seguo, altro non mi interessa) meglio di altre configurazioni.

In questo senso è indubbio che le variabili in gioco sono:

1. sorgenti di squeezelite (patch si, patch no)
2. parametri di compilazione (makefile ed opzioni)
3. sistema target (preconfigurato / taylor made) ipotizzando la stessa architettura di riferimento
4. architettura di riferimento

Propongo di verificarli e smarcarli nell'ordine.

Non capisco cosa ci sia di sbagliato in ciò, tu cosa proponi in altrernativa?

Inizio a pensare che sei in malafede....

Questo Tread parla:
- dell´installazione Di Gentoo (come aspetto principale!!!)
- installare squeezelite su gentoo (con il medoto che ha scelto chi ha preparato questa guida (IO!)...tu puoi seguire quello che vuoi nessuno ti obbliga..é chiara quale seguiresti e va benissimo...seguila!...non obbligare noi a seguire te!!)
- Usare NAD e installare MPD

Puoi fare anche un post qua di come usare il binario in Gentoo (sarebbe piú utile delle chiacchiere) nessuno te lo vieta.


Quello che pensi é chiaro!!! l hai ripetuto talmente tante Volte!!!

Puoi/si possono (non mi ci metto io) fare tutte le prove che vuoi...non in questo TREAD!!! lo stai inquinando dall´inizio...
Aprine un´altro o come vuoi non qua.

[UnixMan]

Ragazzi, calma!

Marco è banalmente perplesso a proposito della scelta dello sviluppatore che ha creato l'ebuild di aggiungere quella patch.

Se non ho capito male, è preoccupato del fatto che, in futuro, la presenza di quella patch potrebbe rendere l'ebuild incompatibile con nuove versioni di squeezelite. Se il punto è questo, IMO si tratta di un non-problema: che "il sorgente" di un pacchetto (in questo caso l'ebuild) sia legato ad una particolare versione (dei sorgenti "upstream") del software che "gestisce" e debba essere aggiornato ogni qual volta esce una nuova versione del software è cosa del tutto normale.

Non di meno, indubbiamente è una scelta curiosa. Se non vado errato, avrebbe potuto ottenere il medesimo risultato banalmente impostando le opzioni di configurazione del "Makefile". Ma, evidentemente, avrà avuto i suoi buoni motivi per fare come ha fatto (magari era banalmente più semplice fare così...).

Comunque sia, per togliersi ogni dubbio, anziché perdere tempo a discuterne qui basterebbe mandargli una e-mail e chiedere lumi direttamente a lui, non credete?

[antonellocaroli]

Ragazzi, calma!

Marco è banalmente perplesso a proposito della scelta dello sviluppatore che ha creato l'ebuild di aggiungere quella patch.

Se non ho capito male, è preoccupato del fatto che, in futuro, la presenza di quella patch potrebbe rendere l'ebuild incompatibile con nuove versioni di squeezelite. Se il punto è questo, IMO si tratta di un non-problema: che "il sorgente" di un pacchetto (in questo caso l'ebuild) sia legato ad una particolare versione (dei sorgenti "upstream") del software che "gestisce" e debba essere aggiornato ogni qual volta esce una nuova versione del software è cosa del tutto normale.

Non di meno, indubbiamente è una scelta curiosa. Se non vado errato, avrebbe potuto ottenere il medesimo risultato banalmente impostando le opzioni di configurazione del "Makefile". Ma, evidentemente, avrà avuto i suoi buoni motivi per fare come ha fatto (magari era banalmente più semplice fare così...).

Comunque sia, per togliersi ogni dubbio, anziché perdere tempo a discuterne qui basterebbe mandargli una e-mail e chiedere lumi direttamente a lui, non credete?

l Overlay é questo:
Gentoo Portage Overlays - media-sound/squeezelite

Che squeezelite cambi cosi tanto che la ebuild non sia compatibile la vedo un po inverosimile comunque.

[marcoc1712]

Ragazzi, calma!

Marco è banalmente perplesso a proposito della scelta dello sviluppatore che ha creato l'ebuild di aggiungere quella patch.

Se non ho capito male, è preoccupato del fatto che, in futuro, la presenza di quella patch potrebbe rendere l'ebuild incompatibile con nuove versioni di squeezelite. Se il punto è questo, IMO si tratta di un non-problema: che "il sorgente" di un pacchetto (in questo caso l'ebuild) sia legato ad una particolare versione (dei sorgenti "upstream") del software che "gestisce" e debba essere aggiornato ogni qual volta esce una nuova versione del software è cosa del tutto normale.

Non di meno, indubbiamente è una scelta curiosa. Se non vado errato, avrebbe potuto ottenere il medesimo risultato banalmente impostando le opzioni di configurazione del "Makefile". Ma, evidentemente, avrà avuto i suoi buoni motivi per fare come ha fatto (magari era banalmente più semplice fare così...).

Comunque sia, per togliersi ogni dubbio, anziché perdere tempo a discuterne qui basterebbe mandargli una e-mail e chiedere lumi direttamente a lui, non credete?

Mi ripeterò, non ve ne abbiate a male...

Quella patch aggiunge un IF ed END IF prima delle include ed a fine sorgente di ogni codec, rendendoli in pratica fogli bianchi..., in funzione dell'opzione di link passata dalla ebuild che la preleva dalla iUSE.

Come metodo è più radicale e stupido di un buldozer, è in completa sovrapposizione con quello standard usato da squeezelite ed ovvviamente funziona solo dove le opzioni sono indicate, quindi per gentoo con quell'ebuild. Non serve aggiungere commenti, è una soluzione quick and dirty per raggiungere uno scopo 'one shot' senza preoccuparsi della manutenzione futura.

A cosa serve? a nulla, se non a 'sganciare' le dipendenze dinamiche anche da flac.c.

EDIT: correggo, oggi a nulla, nella prima versione c'era un problema di disponibilità di librerie in gentoo, per cui non era possibile compilare senza rimuovere in qualche modo alcune dipendenze.

I files toccati sono tutti codec.c + decode.c, quindi sorgenti non interessati da R2, ma direttamente dallo standrd di Triode (o quello mantenuto oggi da Ralphy), quindi volendo fare accogliere la modifica (con le dovute correzioni per renderla compatibile con le versioni portabili) dovrei convincere lui o rendere R2 incompatibile giusto per questo.

Ci sono controindicazione nel non applicarla? No, tranne che libflac.h dovrà essere presente sul sistema di compilazione. Se si vuole correggere questo, si applica a flac lo stesso metodo usato in squeezelite per gli altri codecs, piuttosto.

Per queste considerazioni ed almeno fino a che nessuno mi segnala altri fatti (es. che con la patch suona meglio, cosa che mi lascerebbe molto perplesso) questa modifica va esclusa da R2, il che non implica che non possa rimanere in quell'ebuild - non compete a me - , nel caso, però, chiedo cortesemente che venga aggiunto un cambio di versione e corrette le note di licensing, così che risulti evidente che NON è R2 (pur originando da li) e non è manutenuta da me. Basta farlo nel contesto della patch.

Il manutentore non è raggiungibile e comunque la sua versione non indirizzava R2 ma prima la versione di Triode e quindi una vecchia di Ralphy. R2 viene puntato solo da questa ultima release.

Di fatto usa il makefile (patchando anche lui, è un patchatore seriale...), ma ha costruito un gioco di incarstri tra USE, OPT ed INCLUDE nei sorgenti che gli ocnsente di 'governare' il tutto con le opzioni di USE nell'ebuild.

Se si conviene che la patch ai osrgenti non serve, la parte di make dell'ebuild si può semplificare moltissimo sostituendola con un semplice makefile dedicato o al limite dipendente dall'architettura (questo manca) così da impostare opportunamnet ei CFLAGS. Il come lo lascio decidere ai sistemisti, ma makefile.min è a mio avviso l'esempio da seguire.

Quanto viene dopo l'emake è quello che fa easetup in debian, nessun problema.

[blueray]

Ho provao a fare un:

emerge - system

ed un

emerge -world

Però il sistema , da quello che ho capito , dice che non può proceder perchè alcune librerie sono "masked"


P.s: più che ascolto questo sistema più mi rendo conto che in tanti anni mai avevo sentito così bene la liquida...

[antonellocaroli]

Ho provao a fare un:

emerge - system

ed un

emerge -world

Però il sistema , da quello che ho capito , dice che non può proceder perchè alcune librerie sono "masked"


P.s: più che ascolto questo sistema più mi rendo conto che in tanti anni mai avevo sentito così bene la liquida...

Probabilmente ti suggerisce anche cosa fare...

--autounmask-write

?

[blueray]

No, ma ho letto qualcosa in rete in pratica devo prendere nota dei pacchetti "masked" ed usare quel comando?

[UnixMan]

Quella patch aggiunge un IF ed END IF prima delle include ed a fine sorgente di ogni codec, rendendoli in pratica fogli bianchi..., in funzione dell'opzione di link passata dalla ebuild che la preleva dalla iUSE.

che guarda caso è proprio lo scopo che si vuole ottenere...

Come metodo è più radicale e stupido di un buldozer, è in completa sovrapposizione con quello standard usato da squeezelite ed ovvviamente funziona solo dove le opzioni sono indicate, quindi per gentoo con quell'ebuild.

e dove altro dovrebbe funzionare, scusa? È un pezzo del "pacchetto" Gentoo, ed è destinata ad essere inclusa ed utilizzata solo da e per quello. Mica è una patch destinata alla distribuzione "upstream"...

I files toccati sono tutti codec.c + decode.c, quindi sorgenti non interessati da R2, ma direttamente dallo standrd di Triode (o quello mantenuto oggi da Ralphy), quindi volendo fare accogliere la modifica (con le dovute correzioni per renderla compatibile con le versioni portabili) dovrei convincere lui o rendere R2 incompatibile giusto per questo.

ma è qui che nasce l'equivoco! Né tu né Triode dovete fare nulla!

Non è cosa che vi riguardi: non è vostro compito (di sviluppatori "upstream") quello di preoccuparvi di come sono fatti i "pacchetti" specifici di una distribuzione. Se mai un giorno farete delle modifiche che renderanno le nuove versioni di squeezelite/R2 incompatibili con quella patch o più in generale con quell'ebuild così com'è ora, sarà compito di chi lo ha creato (o di chi vorrà farsene carico) metterci mano per adeguarlo alla nuova versione.

Non siete mica voi a dovervi adeguare, ci mancherebbe altro!

Ciò ovviamente a meno che tu non voglia "adottare" personalmente quell'ebuild, e farti carico anche del suo sviluppo. Nel qual caso puoi fare un po' come ti pare... ma in realtà solo fino a un certo punto. Perché devi rispettare limiti, vincoli, convenzioni e standard imposti dalla distribuzione (in questo caso Gentoo) e dai suoi strumenti di gestione del software, di creazione e compilazione automatica dei pacchetti, ecc. Facendolo, ti accorgeresti ben presto che la "libertà" di chi crea i "pacchetti" per una distribuzione è estremamente limitata. Molte scelte che viste "dall'esterno" potrebbero apparire incomprensibili, spesso in realtà sono praticamente obbligate.

(non conosco abbastanza Gentoo per poter dire se dietro al caso in questione ci sia proprio qualcosa del genere, ma è possibile).

Di fatto usa il makefile (patchando anche lui, è un patchatore seriale...), ma ha costruito un gioco di incarstri tra USE, OPT ed INCLUDE nei sorgenti che gli ocnsente di 'governare' il tutto con le opzioni di USE nell'ebuild.

Proprio per questo non escluderei affatto che si tratti di una serie pratiche "standard", adottate in modo più o meno analogo da tutti gli "ebuild" allo scopo di consentire l'estrema flessibilità e configurabilità del sistema... che è una delle principali caratteristiche nonché raison d'être di Gentoo.

D'altro canto anche gran parte dei pacchetti Debian (e di quelli RedHat, ecc) sono pieni di patch ai sorgenti, ai Makefile, ecc. È una pratica comune, diffusissima e spesso inevitabile per permettere l'integrazione dei diversissimi software negli altrettanto diversi sistemi. Ma non è nulla di cui gli sviluppatori "upstream" si debbano preoccupare in alcun modo.

[antonellocaroli]

Prima che modifico la ebuild, chiedo a chi ha mosso obiezioni se va bene:

-Aggiungo la HomePage dei sorgenti :

https://github.com/marcoc1712/squeezelite-R2

-Cambio il nome da Squeezelite-R2 a squeezelite-NX (é necessario?) l´overlay di gentoo é pieno di ebuild con patch, ma credo che nessuno abbia mai chiesto di cambiare il nome neanche LMS
-per i file di license vengono scaricati direttamente nei sorgenti, presumo non debba fare niente.