[tool]portage-bashrc-ng

[Ferdinando]

/EDIT: (by [equilibrium])

per l'installazione e configurazione del tool consultate il sito del progetto GeCHI Overlay, che ospita il tool portage-bashrc-ng e ne mantiene lo sviluppo.

se riscontrate problemi con l'ebuild o il tool, non segnalateli sul bugzilla di Gentoo, bensì sul bugtracker del progetto --> portage-bashrc bugzilla

NOTA: le informazioni riportate in questo post possono non essere aggiornate ed esatte.

----

Ciao a tutti.

Per chi non conoscesse il tool di Fonderiadigitale, [topic=340329]portage-bashrc[/topic] è un bashrc che viene importato da portage e aggiunge ad esso la funzionalità di compilare in ram anziché sul disco; il bashrc di Fonderia al momento non funziona su versioni di portage superiori alla 2.1-pre6, e richiede un hack. Dopo aver cominciato a modificare portage-bashrc ho deciso di proseguire introducendo nuove funzionalità e semplificando un po' il codice; alla fine è diventato qualcosa di più, e il bashrc adesso serve solo a chiamare alcune funzioni in una lista di moduli, aumentando a piacere le funzionalità di portage.
Il progetto è su sourceforge, e potete leggerne gli sviluppi con un lettore RSS (es. thunderbird, firefox, straw o akregator) da questo feed RSS. Notare che il feed è in inglese, come il changelog e i commenti nel codice; allo stato attuale questo thread è l'unica fonte di informazione in italiano.

Avvertenze
Come potete immaginare, questa nuova versione è altamente sperimentale, per cui, vi prego, non testatela su sistemi mission-critical, e comunque sappiate che non mi assumo responsabilità per corruzioni di portage e/o altri danni: c'è da dire che l'entità dei danni dovrebbe essere minima (forse una compilazione fallita o su disco invece che su ram), ma non sono in grado di assicurarlo.
BIG FAT WARNING: prima di riportare un bug che abbia a che fare con portage, disattivate il bashrc con 'mv /etc/portage/bashrc /etc/portage/bashrc.bk' e riprovate. Ovviamente se incollate dell'output su bugs.gentoo.org quando il bashrc è attivo avete ottime probabilità che il bug sia marcato INVALID.

Come si usa
Innanzitutto per installarlo bisogna emergere e attivare layman:

Code: Select all

# emerge layman
# echo "source /usr/portage/local/layman/make.conf" >> /etc/make.conf

poi scaricare l'overlay:

Code: Select all

# layman -f -o http://gechi-overlay.sf.net/layman.xml -a gechi

quando vorrete controllare la presenza di una nuova versione vi basterà eseguire

Code: Select all

# layman -s gechi

e il nuovo ebuild, se presente, comparirà nel vostro consueto emerge --update.[*]

Modulo tmpfs
Questo modulo permette di compilare su ram+swap anziché su disco; per attivarlo è sufficiente eseguire:

Code: Select all

#eselect bashrc-ng enable tmpfs

Modulo per-package
Questo modulo permette di modificare $CFLAGS, $CXXFLAGS e $FEATURES a seconda del pacchetto, originalmente scritto da Ned Ludd (solar) e modificato da Ryan McIntosh (thebigslide): la versione originale si trova qui, ma è stato modificato prima da me e poi da comio, perciò è ormai un po' diverso dall'originale. Per attivarlo:

• Per le CFLAGS: inserire in /etc/portage/package.cflags il pacchetto e le flags con la solita sintassi (es. "app-arch/unzip -pipe -funroll-loops"), ma è possibile specificare anche solo una categoria (es app-arch). È anche possibile utilizzare il file /etc/portage/package.nocflags per filtrare le flags indesiderate.
• Per le CXXFLAGS: la sintassi è la stessa del precedente, ma il file è /etc/portage/package.cxxflags; è anche possibile utilizzare il file /etc/portage/package.nocxxflags per filtrare le flags indesiderate.
• Per le LDFLAGS: al solito, il file è /etc/portage/package.ldflags; è anche possibile utilizzare il file /etc/portage/package.noldflags per filtrare le flags indesiderate.
• Per le FEATURES: idem come sopra, il file è /etc/portage/package.features; è anche possibile utilizzare il file /etc/portage/package.nofeatures per filtrare le flags indesiderate.

Modulo localepurge
Questo modulo semplicemente invoca localepurge, se è presente, dopo ogni installazione: idea originale di Diego Pettenò (flameeyes). Per attivarlo, quindi, basta emergere app-admin/localepurge.

Modulo autopatch
Questo modulo applica automaticamente le patch scelte dall'utente dopo ogni installazione. Ho semplicemente adattato lo script originale di solar. Per attivarlo occorre impostare la variabile PATCH_OVERLAY in /etc/portage/bashrc-ng/bashrc-ng.conf (es. PATCH_OVERLAY=/usr/portage/local/patches/), e all'interno della directory a cui questa fa riferimento ricreare la struttura di un overlay (quindi una patch per unzip sarà nell'esempio precedente a /usr/portage/local/patches/app-arch/unzip/mypatch.patch).

Modulo ResumeMerge
L'obiettivo di questo modulo è di mantenere i sorgenti già decompressi dal tarball nel precedente emerge quando questo fallisce; se poi questi sono anche stati già compilati viene saltata anche quella fase. L'utilità maggiore si ha in congiunzione col modulo tmpfs, quando la partizione tmpfs viene sottodimensionata e l'emerge fallisce per motivi di spazio: in tal caso se si cambia la dimensione e riprende l'emerge le fasi già svolte vengono saltate.

Moduli personalizzati
Se si desidera scrivere un modulo personalizzato, basta creare uno script bash e chiamarlo /etc/portage/bashrc-ng/mymodule.module, rispettando le seguenti regole. Non esitate a inviarci i vostri moduli se pensate che possano essere utili ad altri.

• Ogni funzione il cui nome corrisponde a una fase di portage col prefisso "on_" verrà invocata all'inizio di quella fase; es. se si scrive on_compile() questa sarà chiamata all'inizio della fase "compile".
• Le funzioni aggiuntive on_BEGIN() e on_END permettono di specificare codice che andrebbe eseguito rispettivamente prima e dopo ogni funzione; non ci dovrebbe essere codice al di fuori delle funzioni perché sarebbe eseguito più volte in ogni fase.
• Affinché il modulo sia utilizzato, ocorre impostare a on il suo nome in /etc/portage/bashrc-ng/bashrc-ng.conf, es. "mymodule=on". Notare che affinché questo funzioni il nome del modulo deve seguire le convenzioni di naming delle variabili bash.
• Per favore non fate scrivere output al modulo al di fuori di una funzione, o diventerà fastidioso, visto che il modulo viene chiamato parecchie volte.
• Per favore implementate ciascuna nuova funzionalità in un modulo separato.
• E' possibile usare le funzioni del bashrc
  • debuginfo(), che stampa i suoi parametri quando DEBUG ha contenuto non-nullo
  • isfeature(), che pone la variabile $itsafeature a 1 se il suo primo parametro è in FEATURES
  • parseconffile(), che controlla se il pacchetto in questione ha un valore specificato nel file che gli è passato come primo parametro, e pone quel valore in $configval; la sintassi è quella di tutti gli /etc/portage/package.*, ed è usata ad esempio per implementare package.mem, package.cflags ecc.
• Non dovreste affidarvi al fatto che una variabile mantenga lo stesso valore tra le chiamate.
• Non dovreste affidarvi al fatto che l'ordine dei moduli resti lo stesso; ad ogni modo, attualmente è alfabetico.
• Non dovreste scrivere su files, ma potete rimuoverli; la ragione è che un utente malizioso potrebbe creare un link ad un importante file di sistema, e usare il vostro codice per sovrascriverlo. Grazie a solar per averlo segnalato.

Note finali
Il tool è ancora in fase di test, come potete vedere dal ChangeLog, perciò finché avrò tempo continuerò ad aggiornarlo e correggere i bug; spero che qualcuno voglia unirsi allo sviluppo e al test, e sono apertissimo ai suggerimenti. Ringrazio veonline e thewally per le ottime idee, fraido, fabius e comio per le patches, e Dr.Dran, !equilibrium e Philantrop per essersi uniti al progetto.
Se siete interessati, per sapere subito quando un bug viene scoperto e corretto vi consiglio di tenere sotto controllo il topic facendo click sul link in fondo alla pagina.
Grazie per l'attenzione

Ciao

[=DvD=]

Lo provo e ti faccio sapere =D

[Ferdinando]

Lo provo e ti faccio sapere =D

Grazie
Un problema di cui sono già a conoscenza è che se si esegue emerge --unmerge monta la dir alla fine (e non dovrebbe montarla affatto), e qualcosa di insolito succedeva anche se il pacchetto è nuovo; invece con upgrade, downgrade e riemersioni dovrebbe andare benone.

Ciao

[Cazzantonio]

lo provo anche io
ovviamente immagino funzioni anche sul portage stabile

[Ferdinando]

ovviamente immagino funzioni anche sul portage stabile

Spero
Non garantisco; fatemi sapere

Ciao

[Cazzantonio]

A me funziona... ha gestito correttamente anche l'upgrade da portage-2.0.54-r2 a portage-2.1

[Dr.Dran]

Interessante, anche io stavo lavorando ad un bashrc tutto particolare, il tuo lavoro comunque per alcuni aspetti mi ha fatto notare alcune incongruenza che non avevo considerato: molto carina la possibilità di definire la memoria per ogni pacchetto e di poter abilitare la funzione di debug
Grazie Ferdinando, ti incoraggio a continuare, poichè questi piccoli scriptini sono di grande aiuto a tutti noi user/devel

Cheers

Franco

[Ferdinando]

Interessante, anche io stavo lavorando ad un bashrc tutto particolare

Sai, thewally stamattina mi ha fatto notare che potevo introdurre nel bashrc anche la personalizzazione di CFLAGS e CXXFLAGS, per cui stavo proprio ora lavorando alla modularizzazione del mio bashrc: in pratica il bashrc chiamerebbe una funzione col nome dello step in tutti i moduli (es. clean(), setup(), compile(), ecc). Tu a che stavi lavorando? Magari si può unire i due progetti: il bashrc una volta messo in piedi non dovrebbe dover essere modificato spesso, e ognuno lavorerebbe al suo modulo. L'idea era di fare un ebuild unico che seleziona i moduli con una USE flag; ciò non toglie che uno possa poi aggiungere i propri moduli semplicemente editando un file in una directory, alla maniera di /etc/cron.daily eccetera.
Che ne pensate?

Ciao

[Ferdinando]

Come dicevo qualche ora fa ho modularizzato il bashrc per introdurre una nuova funzionalità, ed ora si apre la strada a molti altri moduli possibili: ad esempio se a qualcuno interessa si può chiedere agli autori se sono d'accordo con l'includere in questo i bashrc esistenti nel forum per [topic=280748]features, cflags e cxxflags personalizzate[/topic] (questo immagino sia migliore del mio) e per [topic=339019]applicare le patches automaticamente[/topic] (questa poi era di un dev). Fatemi sapere se pensate che sia utile, non mi va di scocciarli se sono features che non interessano a nessuno; anche se, essendo sotto GPL2 anche quelli, non dovrei avere problemi in ogni caso a includere il codice con una semplice nota nei commenti.
Comunque, ovviamente il fatto che ora i files sono più di uno porta il problema di usare un meccanismo automatico; domani cerco di buttar giù un ebuild e uno script di aggiornamento da mettere in /etc/cron.daily per cercare nuove versioni automaticamente. Cerco di sfruttare il tempo il più possibile perché da mercoledì potrei avere meno tempo a disposizione.

Ciao

P.S. Scusate l'up a meno di 24 ore, ma così partono le email

[Cazzantonio]

mi sembra una cosa valida... fossi in te lo pubblicizzerei ai dev dopo aver fatto un ebuild da proporre in portage...
mi sembra inoltre sensato contattare anche i dev degli altri moduli per bashrc

Edit: Ho aggiunto questo post tra i Tool visto che me ne ero dimenticato finora

riedit:
una domanda.... come mai il comando "df" nn mi riporta la dimensione del ramdisk montato dal bashrc?
prima lo faceva... ora non vedo proprio la riga... eppure in mtab è visto come montato...

[Ferdinando]

una domanda.... come mai il comando "df" nn mi riporta la dimensione del ramdisk montato dal bashrc?
prima lo faceva... ora non vedo proprio la riga... eppure in mtab è visto come montato...

Probabilmente come valore della dimensione hai un numero senza il modificatore M (ad esempio PORTAGE_MEMSIZE=500 invece di PORTAGE_MEMSIZE=500M); non so perché mount si comporti in questo modo strano, anche perché la partizione sembra montarla effettivamente in mega, ma poi non compare in df. Il fatto è che il bashrc di Fonderia faceva calcoli complicatissimi per ovviare a questo problema, ma a me è sembrato superfluo, o quantomeno la fatica non valeva il guadagno.

Ciao

[codadilupo]

Dopo aver cominciato a modificare portage-bashrc ho deciso di proseguire introducendo nuove funzionalità e semplificando un po' il codice; l'ho annunciato sul suo thread ma è passato inosservato, e Fonderia al momento sembra assente dal forum, per cui le modifiche non possono essere integrate nell'originale, così ho deciso di forkare il progetto.

beh, esistono i pm

[*] Sono possibili più emerge contemporanei in ram, purché non si superi la dimensione di ram e swap.

uhmm... non mi pare una cosa sensata: piu' emerge sono comunque da sconsigliare, imho

Su tutto il resto, ottime idee, e ottimi sviluppi!

Coda

[Ferdinando]

uhmm... non mi pare una cosa sensata: piu' emerge sono comunque da sconsigliare, imho

Vero, però è un peccato che un po' tutti abbiamo commesso almeno una volta, e non posso dire di non capire se mentre si sta emergendo ad esempio openoffice si vuole avere la possibilità di emergere un pacchettino piccolo piccolo e senza altre dipendenze. Certo, magari un warning non ci starebbe male.

Ciao

[Dr.Dran]

@Ferdinado
Benissimo, anche i ostavo studiando i bashrc di Solar che comprende le fatures che hai incluso tipo configurazione di CFLAGS/CXXFLAGS/LDFLAGS di ogni pacchetto + la features dell'autopatching... solo che la suo soluzione non mi sembrava a plugins, ma credo che si a+ efficiente la tua tenendo conto di una politica a pattern, cioè un core solido espandibile con tremila plug

Inoltre opterei per inserire anche una funzione di localepurge, come suggeriva il mitico Flameeyes in modo tale da eliminare tutti i fil .po e altro di lingue che non ci interessano, questo ad ogni post-installazione e inoltre volevo fare in modo che ad ogni installazione si possa fare il prelink dell'applicazione.

Unire le nostre forze? Ovviamente CERTO eh eh eh!!!

Inizierei con lo strutturare meglio la gerarchia: (sempre se poi si ha intenzione di proporre il pacchetto ai dev )

/etc/portage
/etc/portage/plugins

Dove in /etc/portage si mantiene il file bashrc mentre nella sottocartella plugins si installano le estensioni.

N.B. Altre indee mi stavano venedo in mente, ma comunque la cosa principale e' che la si potrebbe sottoporre ai dev e chissà se non venga accolta come lo script della bash-completion... veramente figo e comodo

Cheers

Franco

P.S. Se vuoi contattami pure tramite p.m. Ciauz

[Ferdinando]

Benissimo, anche i ostavo studiando i bashrc di Solar che comprende le fatures che hai incluso tipo configurazione di CFLAGS/CXXFLAGS/LDFLAGS di ogni pacchetto + la features dell'autopatching... solo che la suo soluzione non mi sembrava a plugins, ma credo che si a+ efficiente la tua tenendo conto di una politica a pattern, cioè un core solido espandibile con tremila plug

Più che altro avevo studiato questa modularizzazione per permettere a chi non vuole di non dover installare funzionalità di cui non ha bisogno (visto che qualcuno protestava per qualche misero byte dello [topic=451492]spinner candy[/topic]), ma l'effetto collaterale di poter integrare altri bashrc con poche modifiche mi è sembrata allettante; visto che quelli di Solar sono su gentoo.wiki, magari lascio una nota sulla pagina di discussione quando ho fatto l'integrazione (naturalmente devo prima leggerli e capirli)

Inoltre opterei per inserire anche una funzione di localepurge, come suggeriva il mitico Flameeyes in modo tale da eliminare tutti i fil .po e altro di lingue che non ci interessano, questo ad ogni post-installazione e inoltre volevo fare in modo che ad ogni installazione si possa fare il prelink dell'applicazione.

Non male; non uso localpurge ma ci vuole poco a verificare se è al suo posto e invocarlo se c'è.
Una cosa che forse aggiungerò ma che non pubblicherò è la compilazione del kernel appena emerso (uso già qualcosa di semiautomatico che fa anche unmerge dei kernel più vecchi, ma fa delle assunzioni su dove tengo i files che non sono estendibili).

Unire le nostre forze? Ovviamente CERTO eh eh eh!!!

Bene

Inizierei con lo strutturare meglio la gerarchia: (sempre se poi si ha intenzione di proporre il pacchetto ai dev )

/etc/portage
/etc/portage/plugins

Dove in /etc/portage si mantiene il file bashrc mentre nella sottocartella plugins si installano le estensioni.

In realtà ho fatto proprio qualcosa di simile (la dir si chiama /etc/portage/bashrc-ng, ma si può cambiare)

N.B. Altre indee mi stavano venedo in mente, ma comunque la cosa principale e' che la si potrebbe sottoporre ai dev e chissà se non venga accolta come lo script della bash-completion... veramente figo e comodo

Proponi, proponi
Che i dev l'accettino a livello ufficiale ne dubito, anche perché Solar è un dev e se non ha ufficializzato i suoi...
Però se si riesce a mettere su qualcosa di stabile si potrebbe aprire un topic su Unsupported Software, e se nessuno grida al dirty hack si potrà aprire un bug di richiesta su bugzilla, ma penso che il cammino per arrivare lì sia lungo.

Ciao

[veonline]

whow!! lascialo solo un secondo e guarda che ti combina il Ferdinando ....


avanti così!!!!!

[Ferdinando]

whow!! lascialo solo un secondo e guarda che ti combina il Ferdinando ....

In effetti devo dire che lo sviluppo ha subito una forte accelerazione negli ultimi giorni, e anche grazie alle vostre idee

Mi preme annunciarvi che ho fatto richiesta di mettere il progetto su sourceforge:

Code: Select all

Project                               Created on       Business days in queue      Status
portage-bashrc-ng (portage-bashrc) 	2006-06-13 11:40           0           Pending Review

Inoltre la nuova versione che trovate qui incorpora i tre moduli aggiuntivi di cui si era parlato ieri e risolve il problema dell'unmerge, che avevo già citato e che riguardava anche lo script originale di Fonderia; per risolverlo ho scelto fasi differenti da quelle di Fonderia, più univoche ma meno "protette", per cui ora il tool tmpfs deve fare un backup della dir prima di montare la partizione e ripristinarlo dopo il montaggio, poco più lento visto che sono solo un file, un link e qualche dir, ma senza dubbio più sicuro. Fatemi sapere se questo dà problemi, perché io uso le FEATURES keepwork e keeptemp, e potrebbe darsi che vada in errore se cerca di rimuovere la dir e non la trova.

Ciao

[fraido]

ciao a tutti,

volevo riportare una brutta esperienza che grazie a Ferdinando sono riuscito a risolvere. Per evitare dup, vi rimando questo link in cui avevo spiegato il mio problema.
Spiego in sintesi cosa mi era successo: avevo installato il bashrc di FonderiaDigitale per compilare in tmpfs, ma col nuovo portage (presumo) ho avuto dei problemi, quindi appena effettuato
update di portage non ero piu' in grado di installare nulla. In particolare i software venivano correttamente compilati, ma in fase di installazione emerge si piantava con uno strano errore:

Code: Select all

make[2]: Leaving directory `/var/tmp/portage/portage/autoconf-2.59-r7/work/autoconf-2.59/doc'
make[1]: Leaving directory `/var/tmp/portage/portage/autoconf-2.59-r7/work/autoconf-2.59/doc'
>>> Completed installing autoconf-2.59-r7 into /var/tmp/portage/portage/autoconf-2.59-r7/image/

!!! install_qa_check failed; exiting.

Scrivo questo post per un duplice motivo. Il primo ringraziare sentitamente Ferdinando per aver visto il mio post tra quelli dei bug di gentoo, aver capito che si trattava di questo problema e quindi avermi aiutato.
Il secondo è dare una mano a chi ha avuto altri problemi simili o dovesse in futuro avere problemi simili; avevo infatti cercato su internet ma non ho trovato altro che un paio di siti(slavi mi pare) e non c'era nulla che mi potesse aiutare(ovviamente vista la causa). A mio avviso è un problema un pò insidioso, in quanto avevo installato il software di Fonderia parecchio tempo fa e non sarei mai arrivato a capire che poteva essere un errore dovuto all'aggiornamento di portage...
spero possa essere utile a qualcuno.
Ciao e grazie Ferdinando!
fraido

[fraido]

ciao di nuovo a tutti,

ho provato il bashrc di ferdinando e propongo una modifica

a riga 168 del file /etc/portage/bashrc-ng/per-package.module circa sostituire:

Code: Select all

einfo "Warning: file /etc/portage/bashrc is altering CFLAGS, CXXFLAGS, FEATURES.";

con:

Code: Select all

if [ -r ${ROOT}/etc/portage/package.features -o  -r ${ROOT}/etc/portage/package.cxxflags -o  -r ${ROOT}/etc/portage/package.cflags ]
then
        einfo "Warning: file /etc/portage/bashrc is altering CFLAGS, CXXFLAGS, FEATURES.";
fi

in questo modo verranno notificati dei warning solo nel caso effettivamente si stia cercando di modificare le cflag, oppure le cxxflags, oppure features.
L'ho provato e da me sembra funzionare.
ciao
fraido

[Ferdinando]

in questo modo verranno notificati dei warning solo nel caso effettivamente si stia cercando di modificare le cflag, oppure le cxxflags, oppure features.

Giusto! Ti ringrazio! E' che quel file è ancora "fresco" e non molto testato; lo aggiungo alla nuova versione.
Comunque in realtà non è che ho visto il tuo bug per caso e ho capito che fosse quello il problema, è che essendo stato uno dei primi a riportarlo su bugzilla sono ancora nella lista di cc, per cui quando Zac Medico ha chiuso il tuo bug come duplicato del [bug=126442]#126442[/bug] io sono stato notificato per email Ma grazie per il caloroso ringraziamento.

Ciao

[fraido]

Giusto! Ti ringrazio! E' che quel file è ancora "fresco" e non molto testato; lo aggiungo alla nuova versione.

beh siamo qui per darti una mano come beta tester, o no?

Comunque in realtà non è che ho visto il tuo bug per caso e ho capito che fosse quello il problema, è che essendo stato uno dei primi a riportarlo su bugzilla sono ancora nella lista di cc, per cui quando Zac Medico ha chiuso il tuo bug come duplicato del [bug=126442]#126442[/bug] io sono stato notificato per email Ma grazie per il caloroso ringraziamento.

Ciao

Allora mi devo ricredere? un dio esiste?
grazie comunque, a tutti per la collaborazione umani e trascendenti che siano!

fraido

[Ferdinando]

Sono lieto di annunciarvi che il tool è da ora su sourceforge: l'homepage del progetto è http://sourceforge.net/projects/portage-bashrc.
Naturalmente per ora non ci sono files, ma domattina lo popolerò. A questo punto l'aggiornamento potrebbe essere segnalato anche tramite il feed RSS.
Non sono molto pratico di sourceforge, ma spero che presto Dr.Dran si unirà al progetto, e con il suo aiuto dovremo riuscire a impostare tutto in breve tempo.

Beh, è tutto per stasera.

Ciao

EDIT: il link per scaricare la versione aggiornata è questo; lo aggiungo anche alla pagina principale. Ho incluso nel modulo per-package la modifica di fraido anche se spezzettata nelle tre funzioni; ci lavorerò ancora per semplificare il codice e per far sì che non dica nulla a meno che non stia davvero modificando le variabili (allo stato attuale basta creare il file perché spuntino i warning) e perché le variabili vengano modificate solo quando serve (immagino CFLAGS e CXXFLAGS solo nelle fasi compile, test e install, e sull'ultima sono in dubbio).

[FonderiaDigitale]

Ciao a tutti.

Per chi non conoscesse il tool di Fonderiadigitale, [topic=340329]portage-bashrc[/topic] è un bashrc che viene importato da portage e aggiunge ad esso la funzionalità di compilare in ram anziché sul disco; il bashrc di Fonderia al momento non funziona su versioni di portage superiori alla 2.1-pre6, e richiede un hack. Dopo aver cominciato a modificare portage-bashrc ho deciso di proseguire introducendo nuove funzionalità e semplificando un po' il codice; l'ho annunciato sul suo thread ma è passato inosservato, e Fonderia al momento sembra assente dal forum, per cui le modifiche non possono essere integrate nell'originale, così ho deciso di forkare il progetto.

Hai fatto bene.
Purtroppo non è un periodo tranquillo questo per me, e lo si vede dall'assenza.

Avevo notato che l'aggiornamento alle versioni sperimentali di portage non funzionava, ma non ho avuto il tempo di aggiustarlo.
Magari quando e se mi fermo può essere che possa contribuire direttamente, vedremo.

Una cosa ti chiedo: prendi in considerazione l'idea di pubblicarlo sotto l'egida dei gechi; il progetto originale cosi come altri tool fatti da altri avevano questa intenzione, e sarebbe carino mantenerne il filone.

Pensaci


a presto se non mi rapiscono gli alieni

[Dr.Dran]

Buona idea posso già eventualmente mettere il progetto all'attenzione di ElDios/DeadHead e gli altru gechi!!!

Cheers

Franco

[Dr.Dran]

Ho avuto l'approvazione da Earcar e DeadHead per accogliere il progetto sotto l'egidia dei Gechi. Beh quindi ora sta a te Ferdinando dare il consenso finale alla cosa eh eh eh

Cheers

Franco