ANNUNCIO: Nuova versione di Squeezelite-R2 disponibile

[marcoc1712]

Ciao,

a seguito del rilascio da parte di Daphile di una versione riveduta e corretta della patch che previene la richiesta di downsampling al server, l'opzione "-h" è stata sostituita da "-x".

Pur trattandosi di una funzionalità minore, ha richiesto il cambio di release in quanto non è compatibile con la versione precedente:

ATTENZIONE: -h adesso restituisce errore.

La documentazione di Squeezelite-R2 è stata aggiornata, e così il link di mia conoscenza.

La nuova versione è, come sempre, recuperabile in gitHub.

Da oggi è disponibile anche la versione compilata per Mac OS X.

[UnixMan]

Acc, avevo appena fatto i nuovi pacchetti...

Altro giro altra corsa. Sempre in "release"? Hai introdotto un qualche numero di versione aggiuntivo, o resta 1.8.1+R2 (e metto solo un -2 alla versione dei pacchetti)?

[marcoc1712]

Acc, avevo appena fatto i nuovi pacchetti...

Altro giro altra corsa. Sempre in "release"? Hai introdotto un qualche numero di versione aggiuntivo, o resta 1.8.1+R2 (e metto solo un -2 alla versione dei pacchetti)?

v1.8.2, non è compatibile con la precedente, quindi ho dovuto cambiare il codice release e non solo il patch level. Cosa devi fare nei pacchetti non lo so, il codice firmware restituito è v1.8.2-(R2).

v. https://github.com/marcoc1712/squeez...eleases/latest

Sorry, ma è il 'rovescio della medaglia' della precednete risposta alla tua giusta lamentela: era -h perchè Daphile lo aveva impostato così, adesso diventa -x per lo stesso motivo. Al di là del fatto che mi pare senza dubbio più corretto, è una questione di rispetto per le fonti.

[marcoc1712]

@Paolo:

La presenza della cartella Debian mi ha creato non pochi problemi (v. le diff su 169 files ed altro), spero di averli risolti e non ne provochino di ulteriori, ma non garantisco sul risultato in Debian, ho dovuto sostituire manualmente un mare di files.

Se hai una copia in una branch locale puoi (dovresti) allineare Release alla mia (pull) ed allineare la tua branch Debian mediante merge. NON tentare in nessun caso un FF dalla mia copia di Debian, probabilmente otterresti un casino. Eventualmente potremmo provare a reintegrare la tua definitiva con una pull request in una versione certamente definitiva.

Lo stesso ho dovuto fare con le cartelle di supporto alla compilazione al netto dei soli files di make.

[UnixMan]

v1.8.2, non è compatibile con la precedente, quindi ho dovuto cambiare il codice release e non solo il patch level. Cosa devi fare nei pacchetti non lo so, il codice firmware restituito è v1.8.2-(R2).

OK, ottimo così.

La presenza della cartella Debian mi ha creato non pochi problemi

?! non capisco come/perché un (sotto)albero "invariante" possa creare problemi... ma finora io ho usato solo CVS, git non lo conosco, per cui non so cosa pensare.

In ogni caso, per il momento, elimina pure il branch "debian". Poi eventualmente vedremo con comodo in futuro se/come fare per tenerlo su github.

[marcoc1712]

?! non capisco come/perché un (sotto)albero "invariante" possa creare problemi... ma finora io ho usato solo CVS, git non lo conosco, per cui non so cosa pensare.

In ogni caso, per il momento, elimina pure il branch "debian". Poi eventualmente vedremo con comodo in futuro se/come fare per tenerlo su github.

Nemmeno io... Io usavo (uso) Mercurial che è un altro livello, prima SVN che aveva i suoi problemi. Con GIT è il meccanismo di inclusione ed esclusione dai commit che mi crea problemi, probabilmnte non lo uso corretamente.

Il 'grosso' problema comunque è GitHub, se committo e faccio push, non ho modo di correggere, se non cancellando le cose sbagliate, committare la cancellazione e reinserirle corrette...

Questo è quanto è successo con Debian... ho comittato mentre ero 'inavvertitamente' su Debian, quindi mi ha inserito tutta la cartella in release, ho dovuto cancellarla manualmente, poi però tornando in Debian qualcosa c'era e qualcosa no.

E' chiaro che ho commesso una disattenzione io, ma cavolo, te lo fa pagare.

Mi è andata peggio con le cartelle per la compilazione in MAC OS X, ...ho perso tutta la branch che avevo fatto in locale, non riuscivo più a pubblicare nulla in remoto, quindi ho dovuto buttare tutto e ripartire dalla situazione remota... Per fortuna ho i backup e posso riprovarci, ma ho deciso che terrò separato l'ambiente di sviluppo e rilascio dei sorgenti da quello di compilazione, così evito problemi, anche se è di una scomodità allucinante.

[UnixMan]

Pronti i nuovi pacchetti Debian con la versione aggiornata.

(rilasciata anche una versione aggiornata dello script easetup.sh che installa quelli).

[marcoc1712]

In ogni caso, per il momento, elimina pure il branch "debian". Poi eventualmente vedremo con comodo in futuro se/come fare per tenerlo su github.

Se non ci sono motivi specifici, non la elimino, l'ho ripulita...

Ma tu come te la sei clonata? Hai un repo in GitHub o no? Se si, nessun problema, se no (come sembra)... Come me la mandi la pull request?

Tutto ciò che segue ha senso se ti serve comparire in Github e rendere evidente il legame e la dipendenza tra i commit dei due repository, altrimenti ti basta il tuo bel clone locale in GIT da cui originerai il tutto a tuo piacimento e puoi evitare di leggere quanto ho scritto qui

Se non usi GitHub:

rimuovo Debian, altrimenti può essere clonata ed usata da altri senza essere aggiornata... nobbuono.

Se usi GitHub:

Avevo visto una fork e non mi sono preoccupato, dando per scontato fossi tu, invece è Krug, quello del mac... Dai un occhio a come si vede il grafico dei branch e capisci perchè sarebbe importante che Debian provenisse da te con i merge da Release.

GIT è lo strumento, ma gitHub è l'ambiente, usare il primo non vuol dire usare il secondo. IN GitHub ogni contributor ha il suo account ed i suoi repository come se fossero locali. Il fatto che poi lavori in remoto e cloni il repo di GitHub è un altro fatto, gestito da Git e di cui GitHub se ne frega. Ma NON puoi contribuire direttamente al repo di un altro in gitHub, se non nella versione enterprise che costa...

Per farlo, devi quindi avere un Repo fork del mio con almeno i branch Debian e Release.

Release lo tieni allineato al mio con dei FF almeno prima dei rilasci, così sei certo di avere sempre l'utima versione del codice, ma non lo modifichi mai, Debian diventa il tuo working space e la tua 'release' vera e propria. Se vorrai propormi mdifiche di altri aspetti, lo farai con un branch dedicato di Release (dopo averlo aggiornato all'ultima verisone, IMPORTANTE).

Così facendo, in qualsiasi momento mi puoi mandare una PULL REQUEST, che essendo allineata all'ultime versione di release, conterrà solo le specifiche modifiche (una volta lo si faceva mandando solo la patch), quindi la procedura prevederebbe la negoziazione, la mia accettazione con eventuale modifica, al che dovresti 'cancellare la tua branch Debian, riclonarti Release, reiniziando il gioco.

In questo modo io rimango il master, tu sei costretto a sincrornizzarti con me e le release devono SEMPRE E SOLO partire dal mio Repo (cioè le devo fare io) altrimenti non sono collegate correttamente.

L'altro modo è che tu origini Debian per branch da Release (nella tua fork) in un momento T, esempio adesso, ci lavori ed ogni qual volta lo ritieni necessario fai una pull di Release per aggiornarla con la mia ed una merge (fast Forward) in Debian, così da rimanere allineato, almeno immediatamente prima di una nuova release.

Puoi quindi decidere o meno di mandarmi la pull request, che io potrei integrare in Release, ricominciando il gioco.

La differenza è:

a. non è necessario, puoi fare le release dalla tua Debian ed è documentato che 'contiene' Release alla versione (commit) x.y. (v. la brench di Krug).

b. ne rimani l'owner così che puoi lavorare con i tuoi ritmi anche diversi ed 'asincroni' rispetto alle mie release (es. puoi saltare il rilascio di qualche mia versione e/o fare rilasci intermedi) utilizzando il commit di Release a cui hai portato il tuo clone, indipendentemente da dove sono io.

DEBIAN origina da Release il 27/11 ed è ancora aperta, non si è mai ricondotta, quindi posso anche solo semplicemnte cancellarla e tu farla ripartire da qualsiasi momento (la crei e ci incolli tutto il codice allo stato).

In quel modo ne ripulisci anche la 'storia' dei commit che - a causa mia - è diventata un po travagliata, ma puoi anche decidere di tenerla , clonarla e lavorare su quella, cambia poco, decidi tu e sappiami dire.

L'unica cosa da evitare è che tu crei una branch di release parallela con dentro la directory Debian, sarebbe un casino da gestire e se qualcuno dovesse fare lo stesso, lavorerebbe su una versione non aggiornata... da evitare.


In ogni caso:

Non sono certo di riuscire a 'cancellare' Debian da Github, questo è il vero problema...ma svuotandola speo a nessuno venga voglia di cercarsi un commit precedente per ripartir eda lì (che comunque si può fare).

[UnixMan]

per il momento non sto usando git/github. Se vuoi mantenere la cartella e/o il branch, sostituisci il contenuto con questo:

http://www.audiofaidate.org/sw/squee..._debian.tar.gz

(già ripulito, ci sono solo i pochi files che servono).

[marcoc1712]

@Giorgio (o chiunque abbia provato): riscontri per la versione OSX ?