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

[antonellocaroli]

Questo dopo emerge -e system


NOTE: Use the '--verbose-conflicts' option to display parents omitted above

It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.


!!! The following installed packages are masked:
- net-libs/libsoup-gnome-2.52.2::gentoo (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Pacho Ramos <pacho@gentoo.org> (21 Aug 2016)
# Obsolete for years in favour of plain libsoup usage. Removal in a month.

- media-video/xanim-2.80.1-r4::gentoo (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Pacho Ramos <pacho@gentoo.org> (20 Aug 2016)
# codecs are not usable, also really obsolete, bug #181959
# Removal in a month.

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

Qualche soluzione te la da....

prova emerge --ask --backtrack=30 system

e vedi cosa ti dice...magari la posti....

opp..prova (ma non mi sembra una soluzione ottimale, visto che ti dice che sono Obsolete)

echo "=net-libs/libsoup-gnome-2.52.2 ~amd64" >> /etc/portage/package.accept_keywords

echo "=media-video/xanim-2.80.1-r4 ~amd64" >> /etc/portage/package.accept_keywords

e poi ridai emerge...

https://packages.gentoo.org/packages.../libsoup-gnome

https://packages.gentoo.org/packages/media-video/xanim

Visto che sono due cose che molto probabilmente non ti servono....puoi anche proseguire cosi

emerge -c libsoup-gnome xanim
emerge --depclean --ask (facendo attenzione a quello che emerge vuole disinstallare)

emerge --ask system

[UnixMan]

la patch ha un senso che mi sfugge?

sì: (verosimilmente) è necessaria per permettere la compilazione di squeezelite-R2 con gli strumenti imposti da Gentoo, secondo i suoi standard.

Si poteva fare diversamente? Probabilmente no.

Così come sono, i sorgenti ufficiali ("upstream") prevedono la possibilità di includere o escludere selettivamente tutte le componenti non strettamente indispensabili agendo solo su variabili di ambiente utilizzate dal Makefile? Se non ricordo male, no.

Se è così, per aderire agli standard di Gentoo è necessario modificare tanto il Makefile quanto i sorgenti. Full stop.


La cosa che forse ti sfugge è che quando crei un "pacchetto" ("sorgente" o binario che sia) per una data distribuzione, il build dai sorgenti non viene fatto "a mano", seguendo i diversissimi metodi previsti da chi distribuisce ciascuna applicazione (sorgenti "upstream"), ma viene fatto in modo automatizzato e standardizzato attraverso degli strumenti specifici. E ci sono tutta una serie di regole specifiche da seguire obbligatoriamente.

Nel caso delle distribuzioni "binarie" (come e.g. Debian, ReHat/Fedora, ecc) il build viene effettuato "a monte", in modo totalmente automatizzato su appositi server dedicati ("build servers") nel caso dei pacchetti "ufficiali", oppure direttamente da chi crea il pacchetto nel caso di pacchetti "isolati" di terze parti (ad es. quelli che ho fatto io). Non di meno, anche in quest'ultimo caso il build non è gestito "a mano" ma eseguito automaticamente attraverso tools appositi.

Ogni diversa distribuzione (o "gruppo" di distribuzioni affini) ha i suoi strumenti e le sue regole, che devono essere seguite nella realizzazione di tutti i pacchetti. Se, come spesso accade, i sorgenti "upstream" (e/o i relativi meccanismi di build previsti all'origine) non permettono il build automatizzato attraverso gli strumenti standard della distribuzione e/o violano qualcuna delle regole, dei vincoli o degli standard che tutti i pacchetti di una data distribuzione devono seguire, nel "pacchetto sorgente" si devono aggiungere delle apposite patch che vanno a modificare come necessario i files della distribuzione ufficiale ("upstream").

Tutto ciò vale anche per Gentoo, con la differenza che in questo caso il build dei "pacchetti" non avviene a priori, su un sistema diverso, ma viene eseguito direttamente (ed automaticamente) al momento dell'installazione sulla macchina dell'utente.

Inoltre - e qui sta la differenza principale tra Gentoo e le distribuzioni "binarie" (che per ovvi motivi non possono fare nulla del genere) - lo strumento di gestione del software di Gentoo ("emerge") consente all'utente di configurare in modo fine (ma sempre attraverso una procedura standard) il software che sta installando. Incluse tutte le "dipendenze opzionali" (oltre alle opzioni di compilazione, ecc).


Tornando nello specifico, se vuoi evitare l'aggiunta di quella patch (o di altre analoghe) devi introdurre delle modifiche equivalenti direttamente nella distribuzione "upstream", modificando tanto i sorgenti quanto il Makefile in modo che sia possibile selezionare -singolarmente- quali librerie (non strettamente indispensabili) includere e quali no semplicemente agendo attraverso il Makefile.
Per quanto riguarda quest'ultimo, ne devi fornire uno solo (o al più uno per ciascun OS supportato) che sia completamente gestibile e "configurabile" attraverso l'uso di opportune variabili di ambiente (senza necessità di modifiche al file).

Diversamente puoi star certo che chiunque debba creare un "pacchetto" per una data distribuzione si troverà a dover aggiungere delle patch per modificare quanto meno il Makefile, se non anche i sorgenti (come nel caso di Gentoo).

In conclusione, riassumendo: le patch in questione non servono per modificare le caratteristiche del tuo software, ma semplicemente per permetterne la corretta integrazione nello specifico sistema.

[blueray]

Qualche soluzione te la da....

prova emerge --ask --backtrack=30 system

e vedi cosa ti dice...magari la posti....

opp..prova (ma non mi sembra una soluzione ottimale, visto che ti dice che sono Obsolete)

echo "=net-libs/libsoup-gnome-2.52.2 ~amd64" >> /etc/portage/package.accept_keywords

echo "=media-video/xanim-2.80.1-r4 ~amd64" >> /etc/portage/package.accept_keywords

e poi ridai emerge...

https://packages.gentoo.org/packages.../libsoup-gnome

https://packages.gentoo.org/packages/media-video/xanim

Visto che sono due cose che molto probabilmente non ti servono....puoi anche proseguire cosi

emerge -c libsoup-gnome xanim
emerge --depclean --ask (facendo attenzione a quello che emerge vuole disinstallare)

emerge --ask system

Ho provato un metodo alternativo Filippo, ho fatto un bel aggiorna pacchetti da interfaccia grafica e dopo ho ridato emerge -e system edesso sembra che vad avanti senza intoppi.
Ne approfitto per suggerire un tweak alla configurazione che influisce sulla qualità di riproduzione ovvero i valori su sysctl.conf di:

vm.dirty_background_ratio
vm.dirty_ratio


atttualmente uso questi:

vm.dirty_background_ratio = 1
vm.dirty_ratio = 15

Con questo comando si possono vedere i"dirtywriteback" e i "nr_writeback" che dovrebbero essere a zero per una migliore resa all' ascolto.

cat /proc/vmstat | egrep "dirty|writeback"

[marcoc1712]

sì: (verosimilmente) è necessaria per permettere la compilazione di squeezelite-R2 con gli strumenti imposti da Gentoo, secondo i suoi standard.

No, non è così. Era così nella versione 1.6, oggi la version standard si compila usando il makefile standard (questo lo riporta Filippo, non io), se vuoi usare opzioni diverse puoi anche patchare il makefile come fa quell'ebuild, ma potresti semplicemente seguire la via maestra di squeezelite e realizzarne uno psecifico per gentoo che lo richiami per le parti comuni.

Per questo dico che è inutile, altrimenti NON sarebbe inutile e QUALSIASI versione per Gentoo avrebbe NECESARIAMENTE bisogno di quella patch o di una analoga, quindi non si potrebbe MAI generare confusione tra la standard senza patch (che non sarebbe possibil eprodurre) e quella patchata.

Questo è il discrimine, ma pare non lo si voglia capire

Si poteva fare diversamente? Probabilmente no.

Certo che si. Se fosse necessario, sarebbe comunque possibile trattare i codecs che nello standard non sono escludibili (flac) allo stesso modo di quelli che lo sono (es. orbis, ffmpeg per alac ed aac, mpg123, mad,...).

Questo, almeno, è quello che fariei io SE fosse necessario, rendendolo disponible ovunque e non solo in gentoo (e di consegenza producendo la versione 1.8.4 (R2)) di suqeezlite in tutte le piattaforme.

Così come sono, i sorgenti ufficiali ("upstream") prevedono la possibilità di includere o escludere selettivamente tutte le componenti non strettamente indispensabili agendo solo su variabili di ambiente utilizzate dal Makefile? Se non ricordo male, no.

No, non tutte, v. sopra.

Se è così, per aderire agli standard di Gentoo è necessario modificare tanto il Makefile quanto i sorgenti. Full stop.

1. non è così e
2. non è necessario, altrimeti non avrei insistito.

Se lo si ritiene migliorativo, allora lo si può fare ma NON limitatamente a gentoo, senza bisogno di realizzae una versione per gentoo (in pratica quello fa la patch) ma POTENDO realizzare un makefile per gentto, ancora una volta è possibile farlo seguendo le modalità usare per gli altri OS, senza inventarsene una speciica per gentto, anche se questo aspetto è molto meno importante.

La cosa che forse ti sfugge ...

No, no mi sfugge, ma per fare tutto qello che dici NON è indispensabile quella patch., Lo fosse, avresti PARZIALMENTE ragione, rimarrebbe preferibile a mio avviso operare in modo diverso, ma sarebbe un altro discorso.

Inoltre - e qui sta la differenza principale tra Gentoo e le distribuzioni "binarie" (che per ovvi motivi non possono fare nulla del genere) - lo strumento di gestione del software di Gentoo ("emerge") consente all'utente di configurare in modo fine (ma sempre attraverso una procedura standard) il software che sta installando. Incluse tutte le "dipendenze opzionali" (oltre alle opzioni di compilazione, ecc)..

L'ho ben capito, ma questo è fattibile DA PROGETTO per chi scrive l'applicazione in diversi modi, es. come fa squeezelite. A mio avviso (ma in realtà non solo mio) l'intervento a gamba tesa per sostituire questo meccanismo con uno diverso ed in sovrapposizione non è una buona pratica, non fosse altro perchè priva di questa possibilità le altre distribuzioni, generando comportamenti diversi della stessa applicazione, NON cercati dal progettista.

La diatriba in merito è di lunga data, ma SE modifichi il comportamento di un'applicazione - in qualiasi modo tu lo faccia - lo devi fare nel rispetto delle regole, che prevedono il rispetto del copyright ed il dare evidenza dell'origine ma anche della avvenuta modifica.

Tornando nello specifico, se vuoi evitare l'aggiunta di quella patch (o di altre analoghe) devi introdurre delle modifiche equivalenti direttamente nella distribuzione "upstream", modificando tanto i sorgenti quanto il Makefile in modo che sia possibile selezionare -singolarmente- quali librerie (non strettamente indispensabili) includere e quali no semplicemente agendo attraverso il Makefile.
Per quanto riguarda quest'ultimo, ne devi fornire uno solo (o al più uno per ciascun OS supportato) che sia completamente gestibile e "configurabile" attraverso l'uso di opportune variabili di ambiente (senza necessità di modifiche al file)..

Esattamente quanto sostengo io, con la differenza - non indifferente - che a mio avviso puoi creare una versione di gentoo con le modifiche che vuoi, manutenerla e distribuila, non c'è bisogno sia io o Raphy o Kimmo a farlo per te. Fai una fork, modifichi il license ed il copyright in modo che sia evidente che è un'alra cosa e vai in pace con Dio.

Farlo in gitHub, google drive, con un apatch o come vuoi non cambia nulla.

La struttura dei makefiles standard e (opzionale) per OS ed architettura è già estatamente come la descrivi sia nello stanard che in R2, ma chi ha fatto quella ebuild, ha preferito usare una patch... libero di farlo, ma poi se la mantiene.

Diversamente puoi star certo che chiunque debba creare un "pacchetto" per una data distribuzione si troverà a dover aggiungere delle patch per modificare quanto meno il Makefile, se non anche i sorgenti (come nel caso di Gentoo)..

NO. Non è mai successo e non ce n'è bisogno, proprio per come è fatto squeezelitee per come sono organizzati i makefile, dai un'occhiata.

Potrai doverti creare il makefile specifico (che richiama quello standrard), ma questo NON modifica le funzionalità di squeezelite ma semplicemente le comanda, non modifica i sorgenti e e quindi lo lascia uguale a se stesso. Non avrebbe senso discriminare la versione prodotta per debian da quella per win, che pur includono ed usano librerie completamente diverse, perchè entrambe sano ESATTAMENTE gli stessi sorgenti.

E' all'insieme dei sorgenti che si riferisce la versione e quanto ne consegue, non alle opzioni di compilazione - manuali o automatiche - utilizzate. Il makefile è nel repository per comodità, ma a stretto rigore, dovrebbero stare in progetti 'figli' per architettura e OS.

In conclusione, riassumendo: le patch in questione non servono per modificare le caratteristiche del tuo software, ma semplicemente per permetterne la corretta integrazione nello specifico sistema.

NO.

a. non sono indispensabili all'integrazione.
b. modificano il codice ed il suo funzionamento (caricano o no dei codecs)

Il tuo punto di vista non tiene conto dei fatti:

a. la patch non è indispensabile,
b. caricare o meno dei codecs è una funzione già compresa in suqeezelite, che comporta un diverso funzionamento e l'emissione di feedback diversi, la patch integra e sovrascrive queste funzionalità provocando un comportamento non coerente.

Non è più squeezelite 1.8.3 (R2), sarebbe opportuno darne corretto feedback all'utente indicando il manutentore del pacchetto e non me come riferimento della versione, esattamente come io ho fatto per modifiche certamente minori, in termini assoluti, rispetto alla versione standard.

A dimostrazione di questo, ipotizza che io (o un terzo) domani rilasci una versione semplificata dell'ebuild senza l'applicazione della patch (come ho più volte scritto sarebbe giusto fare).

Spero converrai che sarebbe una situazione da evitare per quanto possibile, ma a quel punto avremmo due versioni diverse di squeezelite v. 1.8.3 (R2) che - a parità di impostazioni di compilazione, producono eseguibili con funzionalità diverse.

Quale delle due è la 'vera' Squeezelite v. 1.8.3 (R2) che corrisponde a quanto descritto dal testo ottenibile lanciando Squeezelite-r2 -? e che indica me come manutentore?

Detto ciò, almeno conveniamo su una cosa: Io non sono in nessun modo tenuto a farmi carico di o ospitare queste modifiche nel repository di R2.

[blueray]

Altre piccole ottimizzaioni per sistemi Gentoo:

https://wiki.sabayon.org/index.php?t...te_your_system

La pagina riguarda Sabayon Linux se ho capito bene ma dovrebbe esser strettamente parente di Gentoo,ho applicato quelle relative a Prelink e della cache su Ram della temp su quest' ultima però non sono del tutto convinto che possa influire sulle prestazioni all' ascolto.

[bigtube]

Sono stato un po' combattuto se fare considerazioni su questa nuova esperienza con Gentoo.
D'altra parte l'impatto prestazionale è di quelli che lasciano il segno. E certamente un senso
esiste.
Qualche tempo fa' facevo la considerazione che in buona sostanza tutti i sistemi linux che ho sperimentato
in questi anni con qualche differenziazione suonano molto bene, talvolta anche avvicinandosi al mio ideale.
Mi chiederete "e quale sarebbe?" Rispondo : "Quello che mi avvicina al suono degli strumenti per fare musica."
Quando cio' accade non ti chiedi mai niente, ascolti e basta e ti appaghi del senso del messaggio della musica.
Tutto si svolge con assoluta naturalezza e coerenza . Ti lasci coinvolgere dal piano piu' alto dell'emozione artistica....e non pensi ad altro.

Ebbene adesso che ho messo assieme tutto il sistema ( faticoso ma interessante)
Cioè:
PC server con Gentoo installato +logitechmediaserver+C3PO
PC Player con Gentoo installato + squeezelite-R2
....posso dire con tranquillita' e convinzione dopo una quindicina di giorni
di convivenza " ma perchè diavolo non ci ho provato prima".
Il balzo è davvero prepotente e non lascia dubbi di sorta.
Questa è sul serio la massima espressione di linux nell'audio domestico nella mia esperienza.
Ha letteralmente bruciato gli avversari ....tipo Coppi e poi gli altri..... Tutto qua' e scusate se posso apparire enfatico
ma sarebbe ingiusto tenerselo per sè.

[blueray]

Non posso che condividere l' espereinza di Giovanni, devo dire che un sistema così fedele veramente "Hi-FI" nel vero senso dela parola non avevo mai sentito in tanti anni di audio ed è probabilmente la cosa più vicina al master originale che abbia mai ascoltato ha solo il difetto che se una registrazione è di cattiva qualità ... :-(
In settimana spero di far sentire il mio setup a casa di un mio amico-collega di lavoro eventualmente vi riporterò le sue impressioni di ascolto.

[bigtube]

Non posso che condividere l' espereinza di Giovanni, devo dire che un sistema così fedele veramente "Hi-FI" nel vero senso dela parola non avevo mai sentito in tanti anni di audio ed è probabilmente la cosa più vicina al master originale che abbia mai ascoltato ha solo il difetto che se una registrazione è di cattiva qualità ... :-(
In settimana spero di far sentire il mio setup a casa di un mio amico-collega di lavoro eventualmente vi riporterò le sue impressioni di ascolto.

Mi fa' piacere pero' fammi capire meglio. Quale player stai usando? Installato come ? Immagino dovrebbe essere con Portage e immagino tu abbia installato MPD.
Calculate direi che non è esattamente come installarsi gentoo che è un sistema che si monta pezzo per pezzo e da subito si conforma all'hardware presente
Insomma le differenze sono piuttosto evidenti.....non so' se gli ambienti possano essere omogenei.
La creazione di un ambiente Gentoo sulla propria macchina è solo in apparenza difficile .
Le difficolta' iniziano dopo la creazione dell'ambiente di base e del kernel.
Sul server io ho dovuto installare dapprima LMS con lo strumento Layman da un overlay esterno a Portage poi l'ambiente grafico (Xorg e poi xfce4) infine per non fare
una compilazione chilometrica Firefox in versione binaria.Poi ho aggiunto un semplice editor di testo. chiuso ....finito. La reattivita' del sistema avviato è formidabile.
Sul Player stessa minestra dopo l'ambiente di base ho abilitato Alsa (gia' presente nel kernel) e poi installato Squeezelite-R2 con l'ebuild data in pasto a Portage. Chiuso.

Ps: il tutto e sul serio un tour de force ma ....si è ripagati...a voglia se lo si è.

[blueray]

Lo so che forse una distro già "precotta" come Calculate non sarà l' ottimale ma ti assicuro che comunque con MPD il risultato all' ascolto è veramente eccellente, straordinario direi e questo, almeno per adesso, mi basta . Non avevo voglia di mettermi a fare tutta quella sequela di comandi e così ho cercato un alternativa "soft" che invoglaisse anche altri a seguire questa strada alternativa .

[bigtube]

Lo so che forse una distro già "precotta" come Calculate non sarà l' ottimale ma ti assicuro che comunque con MPD il risultato all' ascolto è veramente eccellente, straordinario direi e questo, almeno per adesso, mi basta . Non avevo voglia di mettermi a fare tutta quella sequela di comandi e così ho cercato un alternativa "soft" che invoglaisse anche altri a seguire questa strada alternativa .

Ma non ne dubito affato Fabrizio.....adesso che hai assaggiato....osa di piu.
Il mio è solo un invito....è un'erta via....mi è costata ore e ore d'impegno....ma ne vale la pena.
MPD è un ottimo server-player....ne trarrebbe gran beneficio penso....anche se io preferisco Squeezelite-R2