# [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, portage-bashrc è 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:

```
# emerge layman

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

poi scaricare l'overlay:

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

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

```
# 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:

```
#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 bashrcdebuginfo(), che stampa i suoi parametri quando DEBUG ha contenuto non-nulloisfeature(), che pone la variabile $itsafeature a 1 se il suo primo parametro è in FEATURESparseconffile(), 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  :Smile: 

Ciao

----------

## =DvD=

Lo provo e ti faccio sapere =D

----------

## Ferdinando

 *=DvD= wrote:*   

> Lo provo e ti faccio sapere =D

 

Grazie   :Smile: 

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   :Rolling Eyes: 

----------

## Ferdinando

 *Cazzantonio wrote:*   

> ovviamente immagino funzioni anche sul portage stabile  

 

Spero  :Exclamation: 

Non garantisco; fatemi sapere  :Razz: 

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  :Very Happy: 

Grazie Ferdinando, ti incoraggio a continuare, poichè questi piccoli scriptini sono di grande aiuto a tutti noi user/devel  :Very Happy: 

Cheers

Franco

----------

## Ferdinando

 *Dr.Dran wrote:*   

> 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 features, cflags e cxxflags personalizzate (questo immagino sia migliore del mio) e per applicare le patches automaticamente (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  :Razz: 

----------

## 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   :Wink: 

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

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

 *Cazzantonio wrote:*   

> 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

 *Ferdinando wrote:*   

> 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  :Wink: 

 *Quote:*   

> [*] 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

 *codadilupo wrote:*   

> 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   :Wink: 

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  :Very Happy: )

/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  :Very Happy: 

Cheers

Franco

P.S. Se vuoi contattami pure tramite p.m. Ciauz  :Very Happy: 

----------

## Ferdinando

 *Dr.Dran wrote:*   

> 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 spinner candy), 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)

 *Dr.Dran wrote:*   

> 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).

 *Dr.Dran wrote:*   

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

 

Bene  :Very Happy: 

 *Dr.Dran wrote:*   

> Inizierei con lo strutturare meglio la gerarchia: (sempre se poi si ha intenzione di proporre il pacchetto ai dev )
> 
> /etc/portage
> 
> /etc/portage/plugins
> ...

 

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

 *Dr.Dran wrote:*   

> 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  :Smile: 

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 .... 

 :Very Happy:   :Very Happy:   :Very Happy: 

avanti così!!!!!

----------

## Ferdinando

 *veonline wrote:*   

> 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  :Very Happy: 

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

```
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: 

```
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   :Wink: 

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

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

con:

```
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

 *fraido wrote:*   

> 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 #126442 io sono stato notificato per email  :Smile:  Ma grazie per il caloroso ringraziamento.

Ciao

----------

## fraido

 *Ferdinando wrote:*   

> 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?   :Wink: 

 *Ferdinando wrote:*   

> 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 #126442 io sono stato notificato per email  Ma grazie per il caloroso ringraziamento.
> 
> Ciao

 

Allora mi devo ricredere? un dio esiste?   :Shocked: 

grazie comunque, a tutti per la collaborazione umani e trascendenti che siano!   :Laughing: 

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

 *Ferdinando wrote:*   

> Ciao a tutti.
> 
> Per chi non conoscesse il tool di Fonderiadigitale, portage-bashrc è 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   :Very Happy: 

Cheers

Franco

----------

## veonline

segnalo una anomalia:

```

[~]  # DEBUG=on PORTAGE_MEMSIZE=500M emerge libstdc++-v3

...

...

...

step /usr/lib/portage/bin/ebuild.sh preinst

step /usr/lib/portage/bin/misc-functions.sh

--- /etc/

--- /etc/env.d/

>>> /etc/env.d/99libstdc++

--- /usr/

--- /usr/lib/

>>> /usr/lib/libstdc++-v3/

>>> /usr/lib/libstdc++-v3/libstdc++.so.5.0.6

>>> /usr/lib/libstdc++-v3/libstdc++.so.5 -> libstdc++.so.5.0.6

>>> Safely unmerging already-installed instance...

No package files given... Grabbing a set.

>>> Original instance of package unmerged safely.

step /usr/lib/portage/bin/ebuild.sh postinst

>>> Regenerating /etc/ld.so.cache...

>>> sys-libs/libstdc++-v3-3.3.4 merged.

step /usr/lib/portage/bin/ebuild.sh clean

rmdir: /var/tmp/portage/libstdc++-v3-3.3.4: Dispositivo o risorsa occupata

>>> No packages selected for removal by clean.

...

...

```

e il tmpfs rimane montato...  :Confused: 

da emerge --info le features che uso sono: FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"

con le featurs keeptemp e keepwork  il problema non si presenta

----------

## Ferdinando

@veonline; grazie per la segnalazione, domani ci guardo.

 *Dr.Dran wrote:*   

> 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  

 

Per me va benissimo  :Smile: 

Scusatemi se ultimamente non mi sono collegato, da domani sarò di nuovo in attività... Intanto solar (mi inchino) ha letto il codice e mi ha suggerito due correzioni, prontamente eseguite; purtroppo al momento non posso uploadarle su sourceforge, lo farò domani.

Ciao

----------

## Dr.Dran

@Ferdinando

Grandioso!!! benissimo mi inchino e sbavo del fatto che il codice di tale applicazione sia stato considerato e in qualche modo approvato da un dev come Solar... e' un mio grande idolo soprattutto per quanto riguarda il mondo embedded di gentoo... mi ha illuminato in molte cose, anche nei contatti su irc che ho avuto con lui  :Very Happy: 

Cheers

Franco

----------

## Ferdinando

 *Dr.Dran wrote:*   

> mi ha illuminato in molte cose, anche nei contatti su irc che ho avuto con lui 

 

Per me invece è stato il "first contact"  :Very Happy: 

Comunque ho uploadato la versione 0.7, che trovate qui; inoltre qui trovate un feed RSS, con cui potete essere informati delle nuove versioni: per leggerlo potete usare thunderbird, akregator o ciò che più vi aggrada.

@veonline; non sono in grado di riprodurre il tuo problema. Controlla che non sia stato risolto "per caso" nella nuova versione.

Ciao

----------

## fabius

Ho prodotto una piccola patch per abilitare/disabilitare dinamicamente i vari moduli. Ho creato il file di configurazione /etc/portage/bashrc-ng/config che nel mio caso è il seguente (autoesplicativo)

```
autopatch 0

localepurge 0

per-package 0

tmpfs 1
```

La patch è questa

```
--- /etc/portage/bashrc.old      2006-06-16 10:06:28.000000000 +0200

+++ /etc/portage/bashrc 2006-06-16 20:39:30.000000000 +0200

@@ -52,7 +52,12 @@

        eval "$EBUILD_PHASE () {

                true

        }"

-       # invoke the module-defined action, if any

-       source $mod

-       $EBUILD_PHASE

+

+       to_exec=`grep $(echo ${mod##*/} | awk -F . '{print $1}') /etc/portage/bashrc-ng/config | awk '{print $2}'`

+

+       if [ "$to_exec" == "1" ] ; then

+               # invoke the module-defined action, if any

+               source $mod

+               $EBUILD_PHASE

+       fi

 done
```

Il massimo ora sarebbe scrivere un modulo .eselect per gestire il file di configurazione   :Wink: 

----------

## Ferdinando

 *fabius wrote:*   

> La patch è questa[...]

 

Mi sembra una buona idea; pensavo di escludere direttamente l'installazione dei moduli indesiderati con delle USE flags nel (futuro) ebuild, ma effettivamente ci può essere la necessità di disabilitare temporaneamente un modulo, e allo stato attuale non è immediato.

Lo aggiungo alla prossima release  :Smile: 

Grazie

Ciao

----------

## skakz

ciao,

dall'ultima versione di portage (2.1.1_pre1 ~amd64) ho questo errore:

```
/usr/lib/portage/bin/ebuild.sh: line 609: emake: command not found

!!! ERROR: sys-apps/pmount-0.9.11 failed.

Call stack:

  ebuild.sh, line 1540:   Called dyn_compile

  ebuild.sh, line 940:   Called src_compile

  ebuild.sh, line 609:   Called die

!!! emake failed

!!! If you need support, post the topmost build error, and the call stack if relevant.
```

----------

## Dr.Dran

Domanda scema: se ovviamente disabiliti il bashrc-ng ti compila perfettamente?

Cheers

Franco

----------

## skakz

eh già.. altrimenti non avrei postato proprio qui..   :Rolling Eyes: 

----------

## Ferdinando

 *darkdude wrote:*   

> dall'ultima versione di portage (2.1.1_pre1 ~amd64) ho questo errore:

 

Sì, ho verificato: è che ora portage imposta un suo $PATH e quindi il bashrc non dovrebbe metterci le mani; per backward compatibility mi tocca usare path assoluti oppure salvare il PATH prima di ogni chiamata.

Grazie per la segnalazione.

Ciao

----------

## Dr.Dran

 *darkdude wrote:*   

> eh già.. altrimenti non avrei postato proprio qui..  

 

eh eh eh hai riagione ho fatto un intervento sciocco  :Very Happy: 

----------

## Ashfoot

Segnalo un'anomalia utilizzando la versione 0.7:

Se ho nel package.mem:

```

gnome-base/gnome 32M

gnome-base/gnome-vfs 32M

gnome-base/gnome-mime-data 16M

gnome-base/gnome-libs 64M

```

Eseguendo

```

sudo emerge gnome-base/gnome

```

Ho il seguente output:

```

Calculating dependencies... done!

>>> Emerging (1 of 1) gnome-base/gnome-2.12.3 to /

>>> checking ebuild checksums ;-)

>>> checking auxfile checksums ;-)

>>> checking miscfile checksums ;-)

 * Mounting /var/tmp/portage/gnome-2.12.3 of [ 32M

32M

16M

64M ]

Usage: mount -V                 : print version

       mount -h                 : print this help

       mount                    : list mounted filesystems

       mount -l                 : idem, including volume labels

So far the informational part. Next the mounting.

The command is `mount [-t fstype] something somewhere'.

Details found in /etc/fstab may be omitted.

       mount -a [-t|-O] ...     : mount all stuff from /etc/fstab

       mount device             : mount device at the known place

       mount directory          : mount known device here

       mount -t type dev dir    : ordinary mount command

Note that one does not really mount a device, one mounts

a filesystem (of the given type) found on the device.

One can also mount an already visible directory tree elsewhere:

       mount --bind olddir newdir

or move a subtree:

       mount --move olddir newdir

A device can be given by name, say /dev/hda1 or /dev/cdrom,

or by label, using  -L label  or by uuid, using  -U uuid .

Other options: [-nfFrsvw] [-o options] [-p passwdfd].

For many more details, say  man 8 mount .

 * Please remember that ccache data dir is outside the newly mounted

 * portage temporary directory, to preserve the spool between merges.

```

Mentre "correggendo" il file package.mem:

```

gnome-base/gnome 32M

#gnome-base/gnome-vfs 32M

#gnome-base/gnome-mime-data 16M

#gnome-base/gnome-libs 64M

```

Tutto funziona correttamente...

A prop Ferdinando un grazzissime per il superlavoro che stai facendo!!!!!!!!

----------

## Ferdinando

 *Ashfoot wrote:*   

> Se ho nel package.mem:
> 
> ```
> 
> gnome-base/gnome 32M
> ...

 

Capisco; non avevo considerato questa possibilità. Basterebbe modificare la linea di grep, ma sto ripristinando il parsing di package.mem che aveva scritto Fonderia; è un po' più complesso ma decisamente più flessibile. Vorrei tanto riuscire a trovare un algoritmo efficiente per fare il parsing dei file di configurazione come quello che utilizza portage; ad esempio vorrei supportare righe come =sys-apps/portage-2.1.1_pre1, il che sarebbe fattibile, ma soprattutto >=sys-apps/portage-2.1.1_pre1, che ora come ora non saprei come gestire. Se qualcuno ha idee al riguardo si faccia avanti  :Smile: 

Grazie Ashfoot.

Ciao

----------

## veonline

 *Quote:*   

> 
> 
> segnalo una anomalia:
> 
> Codice:
> ...

 

 *Quote:*   

> 
> 
> @veonline; non sono in grado di riprodurre il tuo problema. Controlla che non sia stato risolto "per caso" nella nuova versione.
> 
> 

 

il problema mi si era presentato con la versione 0.6 e succedeva anche con il pacchetto nvidia-settings.

ora tengo le features in questione disabilitate ma con la versione 0.7 non si è mai presentato...

----------

## Ferdinando

@veonline: mi fa piacere  :Smile: 

Annuncio la versione 0.8, che potete scaricare da qui; dovrei aver risolto i due problemi su citati, in particolare quello segnalato da darkdude. Inoltre ho aggiunto il file di configurazione proposto da fabius, ma non mi soddisfa molto perché ad ogni aggiornamento viene sovrascritto; banalmente potrei decidere che se il file non esiste tutti i moduli si intendono attivati, e non distribuire il file, ma vedo se c'è una soluzione più elegante. Poi quando avremo un ebuild dovremo seriamente pensare a dove tenere questi files, visto che per ogni modifica a un file in /etc è richiesto etc-update e nel caso dei moduli è difficile che l'utente abbia motivo di rifiutarne l'aggiornamento; ma ci penseremo quando avremo un ebuild.

Ciao

----------

## skakz

it works like a charm   :Mr. Green: 

edit:

visto che questo tool è in piena evoluzione propongo la mia:

perchè non aggiungere anche un modulo che esegue etc-update o meglio ancora dispatch-conf alla fine di ogni compilazione? 

considerando che 

1) con una adeguata configurazione i file di cui viene proposto l'aggiornamento diventano davvero pochi 

2) è comunque una cosa positiva per le successive compilazioni avere i file di configurazione aggiornati

3) essendo un modulo può sempre essere disabilitato

4) è di facile implementazione if [ `find /etc/ -iname '._cfg????_*' | sed -e 's://:/:g'` ]; then dispatch-conf; fi

5)varie & eventuali!

ps: da considerarsi come una semplice proposta scartabile senza nessun rimorso   :Wink:  (io lo sto già usando!)

----------

## Dr.Dran

@darkdude

Direi che e' una ottima idea, per il momento sto scrivendo un plug per fare un po' di pulizia nella cartella /usr/portage/distfiles e in /var/tmp (anche perche' la ccache non viene eseguita in tmpfs) e pensavo di utilizzare come applicazione tmpreaper e inoltre sto studiando un sistem per segare i kernel troppo vecchi tutto in un unico plug. Mo vi faccio sapere.

P.S. Se avete anche qualche altro particolare da monitorare per evitare che portage scoppi fatemelo sapere

Cheers

Franco Tampieri

EDIT: @Ferdinando si potrebbe anche scegliere una soluzione spicciola come gentoo fa di default con il make.conf: creare un file che si chiama config.example con le opzioni documentate e poi lasciare all'utente il compito di personalizzare il tool e inoltre si puo' fare come dici tu di considerare di default abilitati o disabilitati tutti i plug se il file config non esiste (io preferirei la seconda, cosi' mi abilito quelli che mi interessano e non faccio danni)

----------

## Ferdinando

 *darkdude wrote:*   

> perchè non aggiungere anche un modulo che esegue etc-update o meglio ancora dispatch-conf alla fine di ogni compilazione?

 

Non è brutta come idea, ma può risultare scomoda se uno lascia il computer a compilare e se ne va; se si era dimenticato di disattivare il modulo già me lo vedo a smadonnare di aver perso qualche ora di compilazione. Una cosa del genere è molto utile alla fine dell'emerge complessivo (uso una cosa simile per automatizzare gli aggiornamenti, che synca, compila, fa revdep-rebuild, mi manda gli einfo  e gli ewarn dell'emersione per posta e poi fa etc-update), ma in tal caso non è fattibile col bashrc. In generale tenderei ad escludere tutto ciò che richiede un intervento diretto dell'utente.

Un altro script del genere lo uso per compilare i nuovi kernel e segare i vecchi: Dr.Dran, pensi che si possa invocare un unmerge dall'interno dell'emerge? Anche se in effetti se ci si limita all'unmerge lo si può far partire in un altro processo.

L'idea del config.example in effetti non è male, anche se aggiunge complessità all'attivazione; ma d'altronde su sourceforge ho classificato il target del progetto come "advanced users"  :Wink: 

Ciao

P.S. Ho creato una piccola homepage del progetto su sourceforge, all'indirizzo http://portage-bashrc.sourceforge.net/, sostanzialmente limitandomi a tradurre in inglese il mio post, che ho anche duplicato su http://portage-bashrc.sourceforge.net/indice.html; magari si potrà usare quello anche per aprire il post su Unsupported Software.

----------

## Dr.Dran

 *Ferdinando wrote:*   

> Un altro script del genere lo uso per compilare i nuovi kernel e segare i vecchi: Dr.Dran, pensi che si possa invocare un unmerge dall'interno dell'emerge? Anche se in effetti se ci si limita all'unmerge lo si può far partire in un altro processo.

 

Effettivamente hai ragione, la cosa potrebbe essere utile se lo si facesse a fine installazione, cioè dopo avere installato l'ultimo pacchetto... bene ci rifletterò eh eh eh anche perchè questo tool non e' che deve fare pure il caffè  :Very Happy: 

 *Ferdinando wrote:*   

>  L'idea del config.example in effetti non è male, anche se aggiunge complessità all'attivazione 

 

Beh d'altronde credo che se uno abbia intenzione di smanettare un pochino non si faccia problemi per editare un file in + al massimo se non fa modifiche portage funziona normalmente senza features evolute  :Very Happy: 

Quindi proporrei una cosa simile:

./bashrc

./bashrc-ng

./bashrc-ng/bashrc-ng.conf.example

./bashrc-ng/*.module

Quindi se crei il fil

 *Ferdinando wrote:*   

> 
> 
> P.S. Ho creato una piccola homepage del progetto su sourceforge, all'indirizzo http://portage-bashrc.sourceforge.net/, sostanzialmente limitandomi a tradurre in inglese il mio post, che ho anche duplicato su http://portage-bashrc.sourceforge.net/indice.html; magari si potrà usare quello anche per aprire il post su Unsupported Software.

 

Beh in futuro la homepage su sf.net la si può rivedere e rendere un pò + pulita  :Very Happy: , comunque per quello che riguarda l'inserimento nel TOPIC dell'unsupported software vai alla grande procediamo assolutamente  :Very Happy:  Io provvedo ad inserirla sul sito dei Gechi  :Very Happy: 

----------

## .:chrome:.

faccio notare una riga che ho avvistato oggi:

 *Quote:*   

> /etc/portage/bashrc-ng/tmpfs.module: line 86: =0: command not found

 

è tra le primissime righe dell'output di compilazione

----------

## Ferdinando

 *Dr.Dran wrote:*   

> Quindi proporrei una cosa simile:

 

Approvo; solo che così i files su cvs non hanno più un rapporto 1:1 con quelli nella release, e mi pare d'aver letto che non si può cambiare i nomi di files e directory senza intervento dello staff di sourceforge. Magari aggiungo a cvs uno script release.sh per generare automaticamente la nuova release a partire dalla struttura cvs.

 *Dr.Dran wrote:*   

> Beh in futuro la homepage su sf.net la si può rivedere e rendere un pò + pulita 

 

Direi proprio di sì  :Razz:  Soprattutto vorrei sistemare la documentazione in forma un po' più organica.

 *Dr.Dran wrote:*   

> comunque per quello che riguarda l'inserimento nel TOPIC dell'unsupported software vai alla grande procediamo assolutamente  Io provvedo ad inserirla sul sito dei Gechi 

 

Ok; domani dopo aver applicato questa modifica creo il topic, e al sito dei Gechi ci pensi tu.

@k.gothmog: grazie, ora controllo, ad occhio direi che mancano un paio d'apici.

EDIT: invece no, c'era un $ di troppo (dannato perl).

Ciao

----------

## skakz

@Dr.Dran: di solito per pulire le directory temporanee e/o la directory distfiles mi affido a app-admin/tmpwatch messo in cron.daily..devo dire che fa egregiamente il suo lavoro.. (anche perchè imho non ha senso fare un controllo ogni pacchetto compilato...)

@Ferdinando in effetti etc-update è più da mettere come ultimo comando magari di un alias del tipo esync='eix-sync -v && etc-update'.. io intato lo continuo ad usare come modulo di bashrc-ng e poi vi faccio sapere come mi sono trovato!

----------

## fabius

 *Dr.Dran wrote:*   

> @EDIT: @Ferdinando si potrebbe anche scegliere una soluzione spicciola come gentoo fa di default con il make.conf: creare un file che si chiama config.example con le opzioni documentate e poi lasciare all'utente il compito di personalizzare il tool e inoltre si puo' fare come dici tu di considerare di default abilitati o disabilitati tutti i plug se il file config non esiste (io preferirei la seconda, cosi' mi abilito quelli che mi interessano e non faccio danni)

 

Premetto che sono favorevole a dei file di configurazione autoesemplificativi. Secondo me però, in questo caso, non c'è bisogno del file di esempio (il file di config è davvero banale  :Smile: ). Un file di esempio ha senso dove ci sono strutture più articolate e ci sono molte opzioni con i relativi commenti (vedi smb.conf o /etc/conf.d/net). In questo modo l'utente ha la possibilità di crearsi il proprio file di configurazione snello e pulito senza perdere il file originale.

Poi, come diceva giustamente Ferdinando, bisogna entrare nell'ottica dell'ebuild che evita la sovrascrittura del file di configurazione ad ogni update. Nell'attesa dell'ebuild basta evitare di scompattare il file di config   :Wink: 

```
# tar --exclude config -xvzf bashrc-v0.8.tar.gz -C /etc/portage
```

oppure si inserisce uno script di installazione nell'archivio

----------

## Dr.Dran

 *darkdude wrote:*   

> di solito per pulire le directory temporanee e/o la directory distfiles mi affido a app-admin/tmpwatch messo in cron.daily..devo dire che fa egregiamente il suo lavoro.. (anche perchè imho non ha senso fare un controllo ogni pacchetto compilato...)

 

Beh conosco perfettamete tmpwatch, ma imho utilizzo app-admin/tmpreaper perchè nella sua sintassi posso inserire dei pattern a mio piacimento,  anche tmpreaper e' assolutamente inseribile in un cronjob e credo che l'utilizzo si leghi solo ad una questione di preferenze e comodità. Comunque sto testando la cosa. Beh sul fare un controllo su ogni pacchetto compilato, beh credo che per me sia + comodo, ma come dico e' solo questione di opinioni.

Cheers

Franco

EDIT:

 *fabius wrote:*   

> Premetto che sono favorevole a dei file di configurazione autoesemplificativi. Secondo me però, in questo caso, non c'è bisogno del file di esempio (il file di config è davvero banale ). Un file di esempio ha senso dove ci sono strutture più articolate e ci sono molte opzioni con i relativi commenti (vedi smb.conf o /etc/conf.d/net). In questo modo l'utente ha la possibilità di crearsi il proprio file di configurazione snello e pulito senza perdere il file originale.

 

Effettivamente il problema visto in questa ottica non si pone. Beh vediamo effettivamente che ne pensa il Lead Developer che è Ferdinando  :Very Happy: 

----------

## Ferdinando

 *Dr.Dran wrote:*   

> Effettivamente il problema visto in questa ottica non si pone. Beh vediamo effettivamente che ne pensa il Lead Developer che è Ferdinando 

 

Grazie della fiducia  :Very Happy: 

Io penso che fabius abbia ragione, però se nel file di configurazione infilassimo tutti i commenti del caso ci risparmieremmo di metterli nell'ebuild; cioè, nella speranza che entri in portage, dobbiamo considerare che molti lo installerebbero per provarlo, senza nemmeno sapere di preciso come si usa (come ho fatto io con klive, installandolo solo perché un dev lo chiedeva). In questo caso, bisogna dare le spiegazioni necessarie nel postinst, e anche se si può includere della documentazione nel pacchetto o dare un link a quella on line, difficilmente l'utente medio ci guarderebbe: se invece l'ebuild dicesse che per attivare le nuove funzionalità occorre creare un file partendo da quello di esempio, l'utente dovrebbe leggere tutti i commenti nel file relativi alle opzioni che gli interessano, e qui gli si potrebbe dire cos'altro deve fare per far funzionare il modulo.

Inoltre non è detto che non si possano aggiungere altre opzioni nel file; in questo caso però occorrerebbe che le righe fossero definizioni di variabili, in modo che il file possa essere sourceato dai moduli che lo richiedono.

Ciao

----------

## Ashfoot

Segnalo un'anomalia utilizzando la versione 0.8:

Se ho nel package.mem:

```

x11-libs/gtk+ 256M

```

Eseguendo

```

sudo emerge x11-libs/gtk+

```

Ho il seguente output: 

```

Calculating dependencies... done!

>>> Emerging (1 of 1) x11-libs/gtk+-2.8.12 to /

>>> checking ebuild checksums ;-)

>>> checking auxfile checksums ;-)

>>> checking miscfile checksums ;-)

>>> checking gtk+-2.8.12.tar.bz2 ;-)

 * Mounting /var/tmp/portage/gtk+-2.8.12 of [ + ]

mount: wrong fs type, bad option, bad superblock on none,

       missing codepage or other error

       In some cases useful info is found in syslog - try

       dmesg | tail  or so

 * Please remember that ccache data dir is outside the newly mounted

 * portage temporary directory, to preserve the spool between merges.

>>> Unpacking source...

>>> Unpacking gtk+-2.8.12.tar.bz2 to /var/tmp/portage/gtk+-2.8.12/work

```

Non viene utilizzato tmpfs e l'output di dmesg è:

```

tmpfs: Bad value '+' for mount option 'size'

tmpfs: Bad value '+' for mount option 'size'

tmpfs: Bad value '+' for mount option 'size'

```

Rimuovendoo la voce in package.mem tutto funziona correttamente.

----------

## Ferdinando

@Ashfoot: argh! Tutto questo perché ho -gnome -gtk -gtk2 nelle USE flag  :Smile:  Purtroppo ho già rilasciato la nuova release e non posso correggere che nella prossima (alla meglio domani). Comunque penso che riscriverò completamente il parsing del file.

Annuncio la versione 0.9. Importante:ora dovete creare manualmente il file /etc/portage/bashrc-ng/bashrc-ng.conf, e se avete /etc/portage/bashrc-ng/config potete tranquillamente cancellarlo;le variabili PORTAGE_MEMSIZE e PATCH_OVERLAY non vanno più impostate in /etc/make.conf ma in /etc/portage/bashrc-ng/bashrc-ng.conf;adesso impostare la variabile PORTAGE_MEMSIZE da riga di comando ha meno priorità del valore impostato in /etc/portage/bashrc-ng/bashrc-ng.conf, se volete sovrascrivere il valore per il singolo emerge usate OVERRIDE_MEMSIZE (es. "OVERRIDE_MEMSIZE=100M emerge ...");inoltre ho aggiunto qualche regola da seguire quando si creano nuovi moduli nel post iniziale.Detto questo, annuncio anche che ho creato il thread su Unsupported Software e ho proposto il tool a Pythonhead perché sia annoverato tra le Portage utilities not in portage (se verrà accolto in portage glielo si comunicherà).

Ciao

----------

## Ashfoot

Allora approfitto prima dell'uscita dell 0.9  :Wink:  :

Se per un qualsiasi motivo mi si blocca un emerge(nel caso specifico perchè la partizione tmpfs era troppo piccola)

es:

```
emerge media-libs/lcms
```

E con nel file package.mem:

```
media-libs/lcms 8M
```

E correttamente l'output di un

```
df -h
```

Risulta

```

Filesystem    Dimens.  Usati Disp. Uso%  Montato su

none            8,0M      8,0M     0   100%  /var/tmp/portage/lcms-1.14-r1

```

Rieseguendo l'emerge dopo avere incrementato le dimensioni dela partizione tmpfs

```
media-libs/lcms 16M
```

Ricevo il seguente messaggio di errore(non bloccante)

```
rmdir: /var/tmp/portage/lcms-1.14-r1: Dispositivo o risorsa occupata
```

Bloccando intenzionalmente l'emerge l'output di un

```
df -h
```

Risulta erroneamente

```

Filesystem    Dimens.  Usati Disp. Uso%  Montato su

none            8,0M      148K     0   2%  /var/tmp/portage/lcms-1.14-r1

```

Probabilmente l'eliminazione della cartella avviene prima dell'umount e quindi rimane montata la partizione tmpfs "vecchia"...

Purtroppo non sono in grado di dire se è un problema di questa versione o anche delle precedenti...

----------

## skakz

c'è questo piccolo errore:

```
>>> Source unpacked.

//etc/portage/bashrc-ng/bashrc-ng.conf: line 47: per-package=on: command not found

>>> Compiling source in /var/tmp/portage/flac-1.1.2-r7/work/flac-1.1.2 ...
```

e anche in altri punti..

altri info:

```
omega ~ # bash --version

GNU bash, version 3.1.17(1)-release (x86_64-pc-linux-gnu)

Copyright (C) 2005 Free Software Foundation, Inc.

omega ~ #
```

```
omega ~ # source //etc/portage/bashrc-ng/bashrc-ng.conf

-su: per-package=on: command not found
```

si risolve se si cambia dappertutto per-package in perpackage

----------

## Ferdinando

@darkdude: in effetti lo avevo cambiato nel mio bashrc-ng.conf ma ho dimenticato di cambiarlo nell'example... mea culpa  :Sad: 

@Ashfoot: tu pensa che quella voleva essere una feature  :Smile:  L'idea era che se la dir era già montata era inutile rimontarla, ma ovviamente se ne cambia la dimensione questo è vanificato; penso che risolverò ricorrendo alla mitica opzione remount.

Intanto Philantrop, un utente tedesco che ha visto il thread su USw, ha inviato un ebuild che devo dire sembra proprio ben fatto  :Cool:  Prossimamente su sourceforge  :Very Happy: 

Ciao

----------

## Ferdinando

Annuncio la versione 0.10, che potete scaricare da qui; ovviamente nella nuova versione ho risolto i problemi su citati.

Il parsing del file ora dovrebbe essere perfetto, tranne che non riesco a supportare atoms come >=$categoria/$pacchetto-$versione, mentre portage lo fa. Qualcuno ha idee di come si possa controllare se la versione lì indicata sia minore o maggiore di quella corrente? Come fa portage, ad esempio, a determinare che 0.10 è maggiore di 0.9, visto che alfabeticamente sarebbe il contrario? Oltretutto il parsing dei singoli numeri è impensabile visto che occorre confrontarlo anche con un 2.1.1_pre1...

Ciao

P.S. Da ora in poi avremo un ebuild! Visto che Philantrop si è unito al progetto, ho chiesto a lui di occuparsene, e probabilmente lo distribuiremo in giornata; la mia idea sarebbe di sfruttare il server rsync di sourceforge: in tal caso dovreste poter ricevere l'update con "rsync -av rsync://portage-bashrc.cvs.sourceforge.net/cvsroot/portage-bashrc/overlay/* /usr/local/portage"  :Cool:  Vi terrò informati sugli sviluppi.

EDIT: come non detto, l'idea precedente è stata scartata  :Sad:  (anche perché devo ancora verificarne la fattibilità), comunque in serata Philantrop uploaderà l'ebuild.

----------

## Cazzantonio

 *Ferdinando wrote:*   

> Come fa portage, ad esempio, a determinare che 0.10 è maggiore di 0.9, visto che alfabeticamente sarebbe il contrario? Oltretutto il parsing dei singoli numeri è impensabile visto che occorre confrontarlo anche con un 2.1.1_pre1...

 

Una soluzione sarebbe usare le stesse funzioni usate da portage... ti garantirebbe anche la compatibilità futura...

comunque per come la vedo io tale feature è un po' inutile   :Wink: 

----------

## Ferdinando

 *Cazzantonio wrote:*   

> Una soluzione sarebbe usare le stesse funzioni usate da portage... ti garantirebbe anche la compatibilità futura...

 

E' vero, ma conosco poco di python e non so se riuscirei a riutilizzarle (farei fatica anche solo a trovarle...  :Rolling Eyes:  comunque domani mi leggo un po' di codice e vedo se le trovo).

 *Cazzantonio wrote:*   

> comunque per come la vedo io tale feature è un po' inutile  

 

Per package.mem forse sì, ma già per package.cflags potrebbe essere utile; ad esempio se si stanno usando flags "spinte" e da una certa versione in poi queste inducono un errore si può ridurle solo da quella versione in poi. Un altro esempio più concreto: le LDFLAGS (che dite le implemento in per-package?) uccidono brutalmente xorg-7, mentre non hanno problemi con tutti gli xorg precedenti. Con pacchetti slotted potrebbe essere utile per avere entrambi gli slot con caratteristiche differenti; ad esempio, tornando a package.mem, gcc mi si compilava in 500M prima di gcc-4, che richiede 800M, e se avessi ancora entrambi gli slots mi potrebbe far piacere non montare 300M in più senza motivo.

Ciao

----------

## fabius

Tieni presente che ci sono anche delle eccezioni in portage per quanto riguarda le versioni degli ebuild. Ad esempio oggi ho notato quella in mplayer

```
[ebuild     UD] media-video/mplayer-1.0_pre8 [1.0.20060415]
```

dove ovviamente non si tratta di un downgrade  :Smile: 

----------

## fabius

Ho creato una prima bozza del modulo eselect per gestire l'abilitazione dei moduli

```
# Copyright 1999-2006 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Id: $

DESCRIPTION="Manage bashrc modules"

MAINTAINER=""

SVN_DATE='$Date: $'

VERSION=$(svn_date_to_version "${SVN_DATE}" )

# find bashrc modules

find_modules() {

   for f in ${ROOT}/etc/portage/bashrc-ng/*.module ; do

      [[ -f ${f} ]] && echo $(basename ${f}) | awk -F . '{print $1}'

   done

}

get_status() {

   local module=${1}

   local conf=/etc/portage/bashrc-ng/bashrc-ng.conf

   if [ -e ${conf} ] ; then

      local status=`grep ^${module}= ${conf} | awk -F \= '{print $2}'`

      if [ "${status}" == "on" ] ; then

         return 1

      else

         return 0

      fi

   else

      return 0

   fi

}

set_status() {

   local module modules=( $( find_modules ) )

   local new_status=${2}

   local conf=/etc/portage/bashrc-ng/bashrc-ng.conf

   if is_number ${1} ; then

      module=${modules[$(( ${1} - 1 ))]}

      if [ "$module" == "" ] ; then

         die -q "'${1}' is an unknown module number"

      fi

   elif has ${1} ${modules[@]} ; then

      module=${1}

   else

      die -q "'${1}' is an unknown module name"

   fi

         

   if [ -f ${conf} ] ; then

      local old_status=`grep ${module}= ${conf} | awk -F \= '{print $2}'`

      if [ "${old_status}" == "on" -o "${old_status}" == "off" ] ; then

         sed -i -e "s:^#*${module}=${old_status}:${module}=${new_status}:" ${conf}

         return 0

      fi

      return 1

   else

      die -q "Configuration file $conf is missing"

   fi

}

###################

### list action ###

###################

describe_list() {

   echo "List available bashrc modules"

}

do_list() {

   targets=( $(find_modules ) )

   write_list_start "Available bashrc modules:"

   if [[ -n "${targets[@]}" ]] ; then

      local i

      for (( i = 0 ; i < ${#targets[@]} ; i = i + 1 )) ; do

         get_status ${targets[${i}]}

         [[ $? -eq 1 ]] && current="on" || current="off"

            

         write_numbered_list_entry "$((i+1))" "${targets[${i}]} $(highlight ${current})"

      done

   else

      write_kv_list_entry "(none found)" ""

   fi

}

#####################

### enable action ###

#####################

describe_enable() {

   echo "Enable a bashrc module"

}

do_enable() {

   if [[ -z ${1} ]] ; then

      # no parameter

      die -q "You didn't tell me which module to enable"

   else

      set_status ${1} on || die -q "Couldn't enable module ${module}"

   fi

}

######################

### disable action ###

######################

describe_disable() {

   echo "Disable a bashrc module"

}

do_disable() {

   if [[ -z ${1} ]] ; then

      # no parameter

      die -q "You didn't tell me which module to disable"

   else

      set_status ${1} off || die -q "Couldn't disable module ${module}"

   fi

}

# vim: set ft=eselect :

```

Last edited by fabius on Wed Jun 21, 2006 9:39 pm; edited 1 time in total

----------

## skakz

 *fabius wrote:*   

> # find a list of kernel symlink targets

   :Rolling Eyes:   :Rolling Eyes:   :Rolling Eyes:   :Rolling Eyes: 

----------

## Ferdinando

 *fabius wrote:*   

> Ho creato una prima bozza del modulo eselect per gestire l'abilitazione dei moduli

 

Grazie fabius, ora non ho molto tempo per testarlo ma lo farò appena possibile; se preferisci puoi joinare il progetto su sourceforge e occupartene direttamente tu (usiamo cvs).

Ciao

----------

## fabius

@darkdude: non si reinventa mica la ruota, no?   :Laughing: 

@Ferdinando: grazie, magari in futuro (ora come ora i miei contributi sarebbero molto irregolari)

----------

## Luca89

 *fabius wrote:*   

> @darkdude: non si reinventa mica la ruota, no?  

 

dove sta l'opensource altrimenti?  :Wink: 

----------

## skakz

[ot]  :Mad:  la mia era soltanto una puntualizzazione fine alla correzione dello script (punto).

tutto il resto lo state facendo e dicendo voi. ammetto che forse era meglio un mp [/ot]

il modulo però l'ho provato e funziona bene  :Smile: 

----------

## Ferdinando

 *darkdude wrote:*   

> il modulo però l'ho provato e funziona bene 

 

Io ho notato solo un problemino sul per-package, ma si dovrebbe risolvere rapidamente con lo stesso passo di tr che ho messo nel bashrc (eliminando il '-'); probabilmente lo troverete nella prossima release  :Wink:  (per la quale probabilmente l'ebuild diventerà il metodo di installazione ufficiale).

Ciao

----------

## fabius

 *Ferdinando wrote:*   

>  *darkdude wrote:*   il modulo però l'ho provato e funziona bene  
> 
> Io ho notato solo un problemino sul per-package, ma si dovrebbe risolvere rapidamente con lo stesso passo di tr che ho messo nel bashrc (eliminando il '-'); probabilmente lo troverete nella prossima release  (per la quale probabilmente l'ebuild diventerà il metodo di installazione ufficiale).

 

C'è qualche motivo particolare per cui la variabile di attivazione del modulo non coincide con il nome del modulo stesso (da cui l'uso di tr)?

----------

## Ferdinando

 *fabius wrote:*   

> C'è qualche motivo particolare per cui la variabile di attivazione del modulo non coincide con il nome del modulo stesso (da cui l'uso di tr)?

 

Solo perché 'per-package=on' non è legale in bash; la vera domanda dovrebbe essere "c'è qualche motivo per cui ad un modulo dovrebbe essere permesso avere nomi con caratteri non alfanumerici?" e la risposta è no  :Smile:  Comincio a pensare che se dalla prossima versione cambio il nome al modulo semplifico la vita a tutti...

Ciao

----------

## fabius

 *Ferdinando wrote:*   

> Comincio a pensare che se dalla prossima versione cambio il nome al modulo semplifico la vita a tutti...

 

Voto per la modifica  :Smile:  (al limite sostituisci - con _)

----------

## .:chrome:.

segnalo un piccolo errore di battitura:

in /etc/portage/bashrc-ng/per-package.module, alla linea 178

exceport invece che export

----------

## Ferdinando

 *k.gothmog wrote:*   

> in /etc/portage/bashrc-ng/per-package.module, alla linea 178
> 
> exceport invece che export

 

Strano, non lo trovo neanche in cvs; comunque /etc/portage/bashrc-ng/per-package.module era solo di 137 righe  :Shocked:  In ogni caso ho fatto un grep su tutti i files e non dovrebbe esserci più.

Ho rilasciato la beta 11 (disponibile qui) e il primo ebuild ufficiale, che siete caldamente invitati a usare, anche perché se no dovreste posizionare a mano la documentazione e il modulo eselect; inutile dire che prossimamente la directory dei moduli troverà una collocazione più adeguata (penso /usr/lib/bashrc-ng). Tra le altre novità, ho incluso il modulo eselect di fabius, il modulo di !equilibrium (che documenterò meglio nel post iniziale), e philantrop ha scritto un po' di documentazione; il modulo per-package, come dicevo sopra, è stato rinominato in perpackage (e ora gestisce anche package.ldflags), perciò vi consiglio di rimuovere il vecchio per-package.module per non confondere il modulo eselect. Quanto all'ebuild per ora le USE flags non sono particolarmente importanti, vengono utilizzate solo con emerge --config, prossimamente selezioneranno i files da installare.

Ciao

----------

## .:chrome:.

evidentemente avevo una versione TROPPO vecchia.

chiedo scusa

----------

## comio

metterei in keywords anche ~amd64.

ciao

----------

## Ferdinando

 *comio wrote:*   

> metterei in keywords anche ~amd64.

 

Sai, mi accorgo solo ora che questo ebuild è solo ~x86  :Shocked:  Grazie per la segnalazione! Per ora aggiungete a mano, domattina fixo in cvs.

Ciao

----------

## comio

 *Ferdinando wrote:*   

>  *comio wrote:*   metterei in keywords anche ~amd64. 
> 
> Sai, mi accorgo solo ora che questo ebuild è solo ~x86  Grazie per la segnalazione! Per ora aggiungete a mano, domattina fixo in cvs.
> 
> Ciao

 

farei inoltre queste modifiche al perpackage.module:

```

# per-package module for portage-bashrc-ng

# Copyright 1999-2005 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /cvsroot/portage-bashrc/portage-bashrc-ng/bashrc-ng/per-package.module,v 1.7 2006/06/21 07:24:42 exairetos Exp $

# Originally written by Ned Ludd (solar_at_gentoo.org)

# modifications by Ryan McIntosh (thebigslide_at_gmail.com)

# V1.0_rc1

# See:http://forums.gentoo.org/viewtopic-t-280748-postdays-0-postorder-asc-start-0.html

# retrieved from http://gentoo-wiki.com/HOWTO_Update_Full_System#5.3_bashrc_for_portage

# adapted by Ferdinando Formica <exairetos@tele2.it> 2006-06-13

# Modified by Luigi Mantellini

# last revision 2006-06-20

GLOBALCONFIG=${ROOT}/etc/portage/bashrc-ng/perpackage.conf

CFLAGS_CONFFILE=${ROOT}/etc/portage/package.cflags

CXXFLAGS_CONFFILE=${ROOT}/etc/portage/package.cxxflags

LDFLAGS_CONFFILE=${ROOT}/etc/portage/package.ldflags

FEATURES_CONFFILE=${ROOT}/etc/portage/package.features

NOCFLAGS_CONFFILE=${ROOT}/etc/portage/package.nocflags

NOCXXFLAGS_CONFFILE=${ROOT}/etc/portage/package.nocxxflags

NOLDFLAGS_CONFFILE=${ROOT}/etc/portage/package.noldflags

NOFEATURES_CONFFILE=${ROOT}/etc/portage/package.nofeatures

filter-flags() {

   local f x VAR VAL

        declare -a new

        

        VAR=$1

        shift

        eval VAL=\${${VAR}}

        for f in ${VAL}; do

           for x in "$@"; do

                   # Note this should work with globs like -O*

                        [[ ${f} == ${x} ]] && continue 2

                done

           eval new\[\${\#new\[@]}]=\${f}

        done

        eval export ${VAR}=\${new\[*]}

}

append-flags() {

   local VAR

   VAR=$1

   

   shift

   

   export $VAR="${$VAR} $*"

   return 0

}

##################

# CFLAGS section #

##################

append-cflags() {

   export CFLAGS="${CFLAGS} $*"

   return 0

} 

package-cflags() {

   # parsing configuration file

   parseconffile "${CFLAGS_CONFFILE}" || return 0

   if [ -n "$configval" ]

   then

      ebegin "Found CFLAGS '$configval' in ${CFLAGS_CONFFILE}: altering CFLAGS"

         unset CFLAGS

         for flag in $configval

         do

            if [ "${flag}" = "GLOBALCFLAGS" ]

            then

               append-cflags $GLOBALCFLAGS

            elif [ "${flag}" = "GLOBALCXXFLAGS" ]

            then

               append-cflags $GLOBALCXXFLAGS

            else

               append-cflags ${flag}

            fi

         done

         export -n CFLAGS

      eend $?

   fi

}

####################

# NOCFLAGS section #

####################

package-nocflags() {

   # parsing configuration file

   parseconffile "${NOCFLAGS_CONFFILE}" || return 0

   if [ -n "$configval" ]

   then

      ebegin "Found CFLAGS '$configval' in ${NOCFLAGS_CONFFILE}: altering CFLAGS"

         for flag in $configval

         do

            filter-flags CFLAGS $flag

         done

         export -n CFLAGS

      eend $?

   fi

}

####################

# CXXFLAGS section #

####################

append-cxxflags() {

   export CXXFLAGS="${CXXFLAGS} $*"

   return 0

}

package-cxxflags() {

   # parsing configuration file

   parseconffile "${CXXFLAGS_CONFFILE}" || return 0

   if [ -n "$configval" ]

   then

      ebegin "Found CXXFLAGS '$configval' in ${CXXFLAGS_CONFFILE}: altering CXXFLAGS"

         unset CXXFLAGS

         for flag in $configval

         do

            if [ "${flag}" = "GLOBALCXXFLAGS" ]

            then

               append-cxxflags $GLOBALCXXFLAGS

            elif [ "${flag}" = "GLOBALCFLAGS" ]

            then

               append-cxxflags $GLOBALCFLAGS

            else

               append-cxxflags ${flag}

            fi

         done

         export -n CXXFLAGS

      eend $?

   fi

}

######################

# NOCXXFLAGS section #

######################

package-nocxxflags() {

   # parsing configuration file

   parseconffile "${NOCXXFLAGS_CONFFILE}" || return 0

   if [ -n "$configval" ]

   then

      ebegin "Found CXXFLAGS '$configval' in ${NOCXXFLAGS_CONFFILE}: altering CXXFLAGS"

         for flag in $configval

         do

            filter-flags CXXFLAGS $flag

         done

         export -n CXXFLAGS

      eend $?

   fi

}

####################

# LDFLAGS section  #

####################

append-ldflags() {

   export LDFLAGS="${LDFLAGS} $*"

   return 0

}

package-ldflags() {

   # parsing configuration file

   parseconffile "${LDFLAGS_CONFFILE}" || return 0

   if [ -n "$configval" ]

   then

      ebegin "Found LDFLAGS '$configval' in ${LDFLAGS_CONFFILE}: altering LDFLAGS"

         unset LDFLAGS

         for flag in $configval

         do

            if [ "${flag}" = "GLOBALLDFLAGS" ]

            then

               append-ldflags $GLOBALLDFLAGS

            else

               append-ldflags ${flag}

            fi

         done

         export -n LDFLAGS

      eend $?

   fi

}

######################

# NOLDFLAGS section  #

######################

package-noldflags() {

   # parsing configuration file

   parseconffile "${NOLDFLAGS_CONFFILE}" || return 0

   if [ -n "$configval" ]

   then

      ebegin "Found LDFLAGS '$configval' in ${NOLDFLAGS_CONFFILE}: altering LDFLAGS"

         for flag in $configval

         do

            filter-flags LDFLAGS $flag

         done

         export -n LDFLAGS

      eend $?

   fi

}

####################

# FEATURES section #

####################

append-features() {

   export FEATURES="${FEATURES} $*"

   return 0

}

package-features() {

    # parsing configuration file

   parseconffile "${FEATURES_CONFFILE}" || return 0

   if [ -n "$configval" ]

   then

      ebegin "Found FEATURES '$configval' in ${FEATURES_CONFFILE}: altering FEATURES"

         unset FEATURES

         for flag in $configval

         do

            if [ "${flag}" = "GLOBALFEATURES" ]

            then

               append-features $GLOBALFEATURES

            else

               append-features ${flag}

            fi

         done

         # checking features for disstcc (maybe we disabled it)

         isfeature distcc

         if [ $itsafeature -eq 0 ] 

         then

            debuginfo Distcc is not used ...

            # I don't like this

            export MAKEOPTS="-j2"

            export OPTIONS="\-distcc"

            unset DISTCC_HOSTS

            export WANT_DISTCC="false"

         fi

         export -n FEATURES;

      eend $?

   fi

} 

######################

# NOFEATURES section #

######################

package-nofeatures() {

    # parsing configuration file

   parseconffile "${NOFEATURES_CONFFILE}" || return 0

   if [ -n "$configval" ]

   then

      ebegin "Found FEATURES '$configval' in ${NOFEATURES_CONFFILE}: altering FEATURES"

         for flag in $configval

         do

            filter-flags FEATURES $flag

         done

         export -n FEATURES;

      eend $?

   fi

} 

##############

# Activation #

##############

compile() {

   export GLOBALCFLAGS=$CFLAGS

   package-cflags

   package-nocflags

   einfo Active CFLAGS = $CFLAGS

   unset GLOBALCFLAGS

   export GLOBALCXXFLAGS=$CXXFLAGS

   package-cxxflags

   package-nocxxflags

   einfo Active CXXFLAGS = $CXXFLAGS

   unset GLOBALCXXFLAG

   export GLOBALLDFLAGS=$LDFLAGS

   package-ldflags

   package-noldflags

   einfo Active LDFLAGS = $LDFLAGS

   unset GLOBALLDFLAGS

   

   export GLOBALFEATURES=$FEATURES 

   package-features

   package-nofeatures

   einfo Active FEATURES = $FEATURES

   unset GLOBALFEATURES 

}

```

così possiamo fare i file package.noXXXX per filtrare le flags.

ciao

----------

## Ferdinando

 *comio wrote:*   

> farei inoltre queste modifiche al perpackage.module:

 

Mi sembra una buona idea; domani testo un po' e aggiungo in cvs. Grazie!

Btw, avete letto che con il nuovo portage /etc/portage/package.* possono essere anche delle dir? Non credo che supporterò mai questo, però  :Rolling Eyes: .

Ciao

----------

## comio

 *Ferdinando wrote:*   

>  *comio wrote:*   farei inoltre queste modifiche al perpackage.module: 
> 
> Mi sembra una buona idea; domani testo un po' e aggiungo in cvs. Grazie!
> 
> Btw, avete letto che con il nuovo portage /etc/portage/package.* possono essere anche delle dir? Non credo che supporterò mai questo, però .
> ...

 

non mi sembra tropo complesso:

```

parseconffile_or_dir() {

   if [[ -d $1 ]]; then

      for file_or_dir in `ls $1`; do

          parseconffile_or_dir $file_or_dir

      done

   else

      parseconffile $1

   fi

}

```

l'ho scritto form scratch... quindi sicuramente non funziona... vedilo come una idea.

ciao

----------

## comio

Un'altra cosa... ma non si può gestire in modo agevole le eccezioni (trap) dentro il bashrc?

Sarebbe interessante l'unmount in caso di fallimento dell'emerge. L'idea era quella di usare "trap"... ma esce un mezzo casino.

qualche idea?

ciao

----------

## .:chrome:.

ho provato ad installare da ebuild

salvo una piccola svista (vero, ferdinando?) è andato tutto bene tranne che per una cosa: CONFIG_PROTECT!!!!

le impostazioni che avevo fatto a mano in bashrc-ng.conf se ne sono allegramente andate a fare in c**o   :Laughing: 

----------

## Ferdinando

 *k.gothmog wrote:*   

> CONFIG_PROTECT!!!!
> 
> le impostazioni che avevo fatto a mano in bashrc-ng.conf se ne sono allegramente andate a fare in c**o  

 

Come? Perché? /etc/portage dovrebbe essere in CONFIG_PROTECT, e oltretutto l'ebuild non dovrebbe installare bashrc-ng.conf, ma bashrc-ng.conf.example... Uhm, ora ci guardo un po'...

Ciao

----------

## Dr.Dran

Strano a me va benissimo, ho pure patchato l'ebuild poiche' io lavoro con la versione stabile di gentoo (a parte qualche cosucci  :Very Happy: ) ho conficurato tutto con eselect e va bene  :Very Happy: 

P.S: L'ebuild non dovrebbe toccare minimamente il file bashrc-ng.conf, a meno che non sia stata installata una versoine vecchia... boh

----------

## fabius

C'è qualche motivo particolare per richiedere tra le dipendenze

```
>=sys-apps/coreutils-5.96

>=sys-devel/patch-2.5.9
```

(mi chiedo il perché delle versioni specifiche indicate). Se piuttosto è sufficiente una scrittura del tipo

```
sys-apps/coreutils

sys-devel/patch
```

(ovvero vanno bene le versioni stabili correnti) mi pare che non sia necessario indicarle espressamente perché sono implicite nella classe system.

----------

## Dr.Dran

In effetti per fare delle prove (e ricordo che ho un ambinete stable a parte il gcc 4.1.1) ho modificato l'ebuild e funziona tutto senza problemi.

Cheers

Franco

----------

## Ferdinando

Quanto all'ebuild l'ho modificato in cvs, e se volete potete scaricare questa variante da qui. Per il resto, scusatemi ma ultimamente ho avuto poco tempo; le modifiche di comio al perpackage.module le ho inserite come patch su sourceforge così se qualche altro sviluppatore con più tempo di me le prova può inserirle in cvs.

Ciao

----------

## !equilibrium

 *fabius wrote:*   

> C'è qualche motivo particolare per richiedere tra le dipendenze
> 
> ```
> >=sys-apps/coreutils-5.96
> 
> ...

 

stessa cosa che ho chiesto io, ma @philantrop vorrebbe tenerle.

comunque ho fatto notare che la versione ~arch di coreutils ha parecchi problemi e bugs:

http://sourceforge.net/tracker/index.php?func=detail&aid=1514403&group_id=169889&atid=852160

spero che la segnalazione venga accolta con buon senso e non come una guerra personale   :Wink: 

----------

## Onip

ho da poco scoperto enotice, un utile strumento che tiene traccia dei vari ewarn ed einfo mandati a schermo durante le emersioni e permette di rivederli (o mandarseli per mail) quando si vuole. Mi chiedevo se potesse essere integrato in portage-basrc-ng come modulo. Purtroppo io non saprei da che parte incominciare...   :Embarassed: 

L'idea è che al termine dell'emerge complessivo di n pacchetti venga lanciato enotice in modo da poter rivedere i vari avvisi

Byez

EDIT: l'ho segnalato perchè ho visto che questo script utilizza un bashrc, precisamente posizionato in /etc/portage/profile/bashc e, dal basso della mia ignoranza, mi ha fatto venire in mente quest'idea

----------

## Ferdinando

 *Onip wrote:*   

> L'idea è che al termine dell'emerge complessivo di n pacchetti venga lanciato enotice in modo da poter rivedere i vari avvisi

 

Pensa che scemo, io avevo scritto la stessa esatta cosa in un mio script bash quando c´era già in giro enotice! Lavoro sprecato, sigh... Io però non saprei come realizzare la cosa in un bashrc, magari vedo un po´ cosa fa enotice di preciso.

Se volete potete aiutare philantrop a decidere quali versioni siano testate rispondendo all´appello che ha fatto sul forum internazionale.

Ciao

P.S. Sto scrivendo da una tastiera qwertz con layout tedesco, penso che tra un po´ comincio a urlare...

----------

## fabius

Domanda scema: ora enotice non è superato con il supporto ELOG di portage?

----------

## Onip

 *fabius wrote:*   

> Domanda scema: ora enotice non è superato con il supporto ELOG di portage?

 

Non lo conoscevo, ma leggendo make.conf.example pare proprio di sì. Al prossimo aggiornamento lo provo

EDIT: provato, fa esattamente (anche più in dettaglio a dir la verità) quello che faceva enotice. Se poi lo si abbina con questo è eccezionale

----------

## Wise

Ciao

complimenti per il lavoro e l' idea!

penso di aver riscontrato un problema con bashrc-ng e i pacchetti che hanno a che fare con il java:

in presenza del file bashrc la compilazione del pacchetto e la compilazione vengono portate a termine...

ma il file jar che contiene le classi compilate non viene installato.. in pratica la libreria risulta correttamente

installata ( installa addirittura la documentazione) ma il jar non c'è!

fermando l' installazione ho e andando a sbirciare dentro a /var/tmp/portage/$pacchetto il jar viene correttamente generato

solo non viene copiato dentro la cartella /var/tmp/portage/$pacchetto/image...

il problema si presenta anche con tutti i moduli disattivati.. scompare solo quando cambio nome al file /etc/portage/bashrc

la versione utilizzata e la 0.11, i pacchetti incriminati sono commons-lang,commons-cli e swt, ma secondo me hanno lo stesso

problema anche tutti i commons-* e in generale tutti i pacchetti che installano librerie java...

spero di essere stato utile.. se hai bisogno di altre informazioni ti accontentero il prima possibile!

----------

## Ferdinando

 *Wise wrote:*   

> i pacchetti incriminati sono commons-lang,commons-cli e swt, ma secondo me hanno lo stesso
> 
> problema anche tutti i commons-* e in generale tutti i pacchetti che installano librerie java...

 

Grazie per la segnalazione; ci guarderò appena possibile. Non mi meraviglia che non me ne sia mai accorto; sul mio sistema gli unici jar appartengono a dei binari...

Grazie ancora

Ciao

----------

## comio

 *Ferdinando wrote:*   

>  *Wise wrote:*   i pacchetti incriminati sono commons-lang,commons-cli e swt, ma secondo me hanno lo stesso
> 
> problema anche tutti i commons-* e in generale tutti i pacchetti che installano librerie java... 
> 
> Grazie per la segnalazione; ci guarderò appena possibile. Non mi meraviglia che non me ne sia mai accorto; sul mio sistema gli unici jar appartengono a dei binari...
> ...

 

effettivamente questo effetto mi capitava... ma non ho pensato al bashrc...

ciao

----------

## !equilibrium

 *Wise wrote:*   

> penso di aver riscontrato un problema con bashrc-ng e i pacchetti che hanno a che fare con il java:
> 
> in presenza del file bashrc la compilazione del pacchetto e la compilazione vengono portate a termine...

 

mi ci sono imbattuto anche io tempo fa, stessi sintomi, ma pensavo fosse un problema del pacchetto che stavo installando e non di bashrc, tant'è che ho aperto pure un bugreport: https://bugs.gentoo.org/show_bug.cgi?id=138589

il problema si è risolto installando la versione unstable di quel pacchetto e delle JDK.

----------

## Ferdinando

 *!equilibrium wrote:*   

> il problema si è risolto installando la versione unstable di quel pacchetto e delle JDK.

 

Ho il sospetto che alcune versioni di qualche pacchetto facciano dei giochetti strani con le variabili d'ambiente (il bashrc non fa molto), ma vi saprò dire solo domani, dopo aver emerso i pacchetti incriminati.

Ciao

----------

## !equilibrium

 *Ferdinando wrote:*   

> Ho il sospetto che alcune versioni di qualche pacchetto facciano dei giochetti strani con le variabili d'ambiente (il bashrc non fa molto), ma vi saprò dire solo domani, dopo aver emerso i pacchetti incriminati.

 

a naso mi pare un problema con i permessi o con le coreutils, non vorrei che l'uso dell'ebuild che forzava la versione unstable delle coreutils fosse la causa. In caso, abbiamo un altro valido motivo per non usare coreutils ~x86 e fare un bugreport del problema.

----------

## Wise

per la cronaca io uso le coreutils stabili.. non ho usato l'ebuild per installare bashrc-ng..

comunque il problema si era presentato con una vecchia versione (tipo 0.10 o 0.7 non so..)

ho aggiornato oggi alla 0.11 per vedere se magari era colpa della versione.

ho pensato anche io fosse colpa del jdk o dell ebuild..ho provato con le versioni ~x86

ma non e cambiato niente..

----------

## Ferdinando

Non so di chi sia la colpa, ma qualcuno definisce una funzione che ha lo stesso nome di quelle del bashrc, e il bashrc opera nello stesso processo di ebuild.sh per poter cambiare le var d'ambiente come CFLAGS, perciò il conflitto è inevitabile. L'unica soluzione che ho trovato è stata cambiare i nomi delle funzioni da $EBUILD_PHASE a on_$EBUILD_PHASE, quindi con queste modifiche al bashrc:

```
diff -wu bashrc bashrc.new

--- bashrc   2006-07-01 15:50:23.086252000 +0200

+++ bashrc.new   2006-07-11 21:18:07.112540500 +0200

@@ -116,7 +116,7 @@

 for mod in ${MODULESDIR}/*.module

 do

    # define an empty action

-   eval "$EBUILD_PHASE () {

+   eval "on_$EBUILD_PHASE () {

       true

    }"

    # source the module, if active

@@ -125,7 +125,7 @@

    then

       source $mod

       # invoke the module-defined action, if any

-      $EBUILD_PHASE

+      on_$EBUILD_PHASE

    fi

 done
```

che potete applicare andando in /etc/portage, scrivendo 'patch -p0' e poi facendo copia-incolla del testo qui su (terminato con ctrl-D); il problema è che bisogna poi aprire in un editor ogni modulo (almeno quelli che usate, nella prossima release saranno tutti corretti) e sostituire clean() con on_clean(), setup() con on_setup(), compile() con on_compile(), install() con on_install(), e postinst con on_postinst(); dovrebbero essere le ultime funzioni in ogni modulo.

Ciao

----------

## comio

 *Ferdinando wrote:*   

> che potete applicare andando in /etc/portage, scrivendo 'patch -p0' e poi facendo copia-incolla del testo qui su (terminato con ctrl-D); il problema è che bisogna poi aprire in un editor ogni modulo (almeno quelli che usate, nella prossima release saranno tutti corretti) e sostituire clean() con on_clean(), setup() con on_setup(), compile() con on_compile(), install() con on_install(), e postinst con on_postinst(); dovrebbero essere le ultime funzioni in ogni modulo.
> 
> Ciao

 

io sarei per rinominarle in modo del tipo bashrc_clean(), bashrc_setup(), ... così dovrebbe essere realmente difficile fare collisione.

ciao

luigi

----------

## Ferdinando

 *comio wrote:*   

> io sarei per rinominarle in modo del tipo bashrc_clean(), bashrc_setup(), ... così dovrebbe essere realmente difficile fare collisione.

 

Ci avevo pensato ma mi sembra un po' triste  :Smile:  Per ora credo che on_ vada bene, magari prima che esca la nuova release ci penso su.

La collisione sulle funzioni è un'eventualità che finora non avevo mai preso in considerazione perché per il modo in cui funziona portage definire una variabile o una funzione e aspettarsi che sia ancora lì al passo successivo è una pessima pratica di programmazione (dopotutto portage è scritto in python quindi è ovvio che la parte bash possa anche essere eseguita in un processo separato a ogni passo), come d'altronde lo è modificare $PN come discutevamo sul forum internazionale; però se portage lo tollera il bashrc si deve adeguare, non c'è dubbio.

Ciao

----------

## comio

domanda: la patch per supportare i files del tipo package.nocflags, ... la metti come ufficiale? io sin ora la sto usando con successo senza avere noie.

ciao

luigi

----------

## Ferdinando

 *comio wrote:*   

> domanda: la patch per supportare i files del tipo package.nocflags, ... la metti come ufficiale? io sin ora la sto usando con successo senza avere noie.

 

Sì l'ho testata anch'io per un po' senza problemi, così insieme a questa patch ho aggiunto (o meglio fatto aggiungere) anche quella in cvs. Il problema ora è che nella nuova versione vorrei risolvere anche il problema che !equilibrium ha trovato riguardo $PN nel tmpfs, e ci sta lavorando lui; quando il nuovo tmpfs sarà stato testato rilascio la beta12.

Ciao

----------

## !equilibrium

 *Ferdinando wrote:*   

> Il problema ora è che nella nuova versione vorrei risolvere anche il problema che !equilibrium ha trovato riguardo $PN nel tmpfs, e ci sta lavorando lui; quando il nuovo tmpfs sarà stato testato rilascio la beta12.

 

p.s.: soprattutto se non volete ritrovarvi l'intera gentoo box cancellata nel giro di pochi minuti  :Wink: 

----------

## Dr.Dran

 *!equilibrium wrote:*   

> p.s.: soprattutto se non volete ritrovarvi l'intera gentoo box cancellata nel giro di pochi minuti 

 

Quoto... è purtroppo capitato anche a me... e ho rimesso tutto a posto un pò a fatica solo ora   :Confused: 

----------

## comio

 *!equilibrium wrote:*   

>  *Ferdinando wrote:*   Il problema ora è che nella nuova versione vorrei risolvere anche il problema che !equilibrium ha trovato riguardo $PN nel tmpfs, e ci sta lavorando lui; quando il nuovo tmpfs sarà stato testato rilascio la beta12. 
> 
> p.s.: soprattutto se non volete ritrovarvi l'intera gentoo box cancellata nel giro di pochi minuti 

 

spiegatemi la faccenda e come riprodurre la situazione "critica"...

ciao

----------

## .:chrome:.

c'è una cosa che mi da un po' fastidio:

ho una entry in /etc/portage/package.features; ogni tanto la cosa viene segnalato durante il calcolo delle dipendenze. la cosa fatsidiosa è però che il messaggio si ripete per diverse volte. ne basterebbe una sola...

so che è una cazzata. non picchiatemi

----------

## Onip

 *k.gothmog wrote:*   

> c'è una cosa che mi da un po' fastidio:
> 
> ho una entry in /etc/portage/package.features; ogni tanto la cosa viene segnalato durante il calcolo delle dipendenze. la cosa fatsidiosa è però che il messaggio si ripete per diverse volte. ne basterebbe una sola...
> 
> so che è una cazzata. non picchiatemi

 

Capita lo stesso con package.cflags (o cxxflags). Segnala che vengono modificate le cflags del pacchetto un po' in ogni fase dell'emersione. Niente di importante, certo, ma quando uscirà da beta forse sarebbe meglio segnalare i cambiamenti solo nella fase appropriata

----------

## comio

 *Onip wrote:*   

>  *k.gothmog wrote:*   c'è una cosa che mi da un po' fastidio:
> 
> ho una entry in /etc/portage/package.features; ogni tanto la cosa viene segnalato durante il calcolo delle dipendenze. la cosa fatsidiosa è però che il messaggio si ripete per diverse volte. ne basterebbe una sola...
> 
> so che è una cazzata. non picchiatemi 
> ...

 

Infatti basta che il tutto il codice sia contenuto solo nella funzione "on_compile" le altre non servono.

```

on_compile() {

        export GLOBALCFLAGS=$CFLAGS

        package-cflags

#       package-nocflags

        einfo Active CFLAGS = $CFLAGS

        unset GLOBALCFLAGS

        export GLOBALCXXFLAGS=$CXXFLAGS

        package-cxxflags

#       package-nocxxflags

        einfo Active CXXFLAGS = $CXXFLAGS

        unset GLOBALCXXFLAG

        export GLOBALLDFLAGS=$LDFLAGS

        package-ldflags

#       package-noldflags

        einfo Active LDFLAGS = $LDFLAGS

        unset GLOBALLDFLAGS

        export GLOBALFEATURES=$FEATURES

        package-features

#       package-nofeatures

        einfo Active FEATURES = $FEATURES

        unset GLOBALFEATURES

}

```

ciao

----------

## Ferdinando

 *comio wrote:*   

> spiegatemi la faccenda e come riprodurre la situazione "critica"...

 

Il problema è che nel modulo tmpfs c'è un infausto "rm -rf ${mounteddir}/*", dove $mounteddir dipende da $PN: se $PN == "" allora $mounteddir == "" e quindi il comando diventa... argh! faccio fatica anche a scriverlo! Beh, avete capito!  :Razz: 

Come riprodurlo: non lo farei se fossi in te, ma scrivi un ebuild che azzeri il contenuto di PN nella fase opportuna e tanto basta. Per fortuna nessun ebuild in portage fa una cosa simile, perciò aspettavo a diffondere la notizia per non creare panico, ma ormai  :Wink: 

Per risolvere il problema basta commentare qualche linea di codice, ma se PN non ha il valore che ci aspettiamo l'intero modulo ha dei problemi, per cui più che una patch vorrei rilasciare un modulo "riveduto e corretto", e visto che la mia comprensione degli ebuild al momento è un po' limitata le mie soluzioni potrebbero non essere adeguate.

Ciao

P.S. Nella patch di comio c'era la modifica di introdurre il tutto in una funzione, quindi lo troverete nella prossima release; io non l'avevo fatto perché le features sono utili anche in fasi diverse dalla compile, e le cflags ad esempio potrebbero esserlo nella fase di test. Comunque aspetto feedback da voi.

----------

## skakz

--preserve-root lo hanno inventato proprio per questo   :Laughing: 

```
omega # rm --preserve-root / -fr

rm: it is dangerous to operate recursively on `/'

rm: use --no-preserve-root to override this failsafe

omega src #
```

----------

## Kernel78

 *skakz wrote:*   

> --preserve-root lo hanno inventato proprio per questo  
> 
> 

 

Come l'hai trovata ? nella pagina man non ne parla  :Confused: 

/EDIT:ma in info rm ne parla ...

----------

## Ferdinando

 *skakz wrote:*   

> --preserve-root lo hanno inventato proprio per questo   

 

Grazie, in effetti questa mi è nuova. Comunque come dicevo più che delle piccole modifiche in questo momento ho in mente una riscrittura più organica del modulo; certo che se ci si mettesse troppo tempo farei una patch e via.

Ciao

----------

## Ferdinando

Alla fine ci ho messo una pezza (patch) e ho fatto una nuova versione, così distribuiamo i fix e possiamo testare con più calma il nuovo tmpfs. Naturalmente siete tutti invitati a passare a questa versione, visti i problemi della precedente. Tre cose:La patch di comio la trovate nella nuova versione, fate attenzione perché ora perpackage.module viene eseguito solo nella fase di compile; se ciò vi dà dei problemi fatemi sapere.Anche il fix per i jars è in questa nuova versione; se state usando dei moduli personalizzati, dovete cambiare i nomi delle funzioni inserendo il prefisso "on_", es. on_compile(), on_install() ecc.Il fix per il problema con $PN è temporaneo ma radicale; non uso più né $PN né $PF, e non chiamo più rm con l'opzione -r. Ciò però implica che se avete un processo con cwd nella dir temporanea (vi ci siete messi per sbaglio con la shell, avete un cronjob di backup scritto male, avete updatedb configurato male) la dir temporanea non sarà smontata né svuotata e alla lunga potreste esaurire lo spazio in RAM.Ciao

----------

## btbbass

Ho un piccolo problema con il modulo bashrc keepwork;

se provo un emerge, lo interrompo, e dopo lo rifaccio partire, ottengo questi messaggi:

```

>>> Emerging (1 of 6) media-libs/xine-lib-1.1.2-r2 to /

 * Trying to resume merge

/etc/portage/bashrc-ng//resumemerge.module: line 14: FEATURES+= keepwork: command not found

rmdir: /var/tmp/portage/xine-lib-1.1.2-r2: Device or resource busy

>>> checking ebuild checksums ;-)

```

poi cmq l'emerge va a buon fine..

Questo è il mio emerge --info:

```

Portage 2.1-r1 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.3.6-r4, 2.6.15-gentoo-r1 i686)

=================================================================

System uname: 2.6.15-gentoo-r1 i686 Intel(R) Pentium(R) M processor 1400MHz

Gentoo Base System version 1.6.14

distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]

app-admin/eselect-compiler: [Not Present]

dev-lang/python:     2.3.5-r2, 2.4.2

dev-python/pycrypto: 2.0.1-r5

dev-util/ccache:     [Not Present]

dev-util/confcache:  [Not Present]

sys-apps/sandbox:    1.2.12

sys-devel/autoconf:  2.13, 2.59-r7

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1

sys-devel/binutils:  2.16.1-r3

sys-devel/gcc-config: 1.3.13-r3

sys-devel/libtool:   1.5.20

virtual/os-headers:  2.6.11-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-Os -march=pentium-m -mmmx -msse -msse2 -pipe -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/lib/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/splash /etc/terminfo"

CXXFLAGS="-Os -march=pentium-m -mmmx -msse -msse2 -pipe -fomit-frame-pointer"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"

GENTOO_MIRRORS="http://www.die.unipd.it/pub/Linux/distributions/gentoo-sources/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://mirror.pudas.net/gentoo http://gentoo.blueyonder.co.uk http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/"

LDFLAGS="-Wl,-O1"

LINGUAS="it"

MAKEOPTS="-j3"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage /usr/local/initng-portage"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

```

----------

## Ferdinando

 *btbbass wrote:*   

> /etc/portage/bashrc-ng//resumemerge.module: line 14: FEATURES+= keepwork: command not found

 

Lol! Io e la mia mania per le scorciatoie... Per un fix rapido apri /etc/portage/bashrc-ng/resumemerge.module e sostituisci

```
FEATURES+=" keepwork"
```

(non avrai problemi a trovare la riga, il file è piccolo) con

```
FEATURES="$FEATURES keepwork"
```

In bash-3 le due scritture dovrebbero essere interpretate allo stesso modo; per curiosità, tu che versione di bash hai?

Ciao

----------

## comio

 *Ferdinando wrote:*   

>  *btbbass wrote:*   /etc/portage/bashrc-ng//resumemerge.module: line 14: FEATURES+= keepwork: command not found 
> 
> Lol! Io e la mia mania per le scorciatoie... Per un fix rapido apri /etc/portage/bashrc-ng/resumemerge.module e sostituisci
> 
> ```
> ...

 

io tendenzialmente eviterei le features della bash3 (quando possibile), così è utilizzabile più facilmente.

luigi

----------

## Ferdinando

 *comio wrote:*   

> io tendenzialmente eviterei le features della bash3 (quando possibile), così è utilizzabile più facilmente.

 

E non sto neanche utilizzando il nuovissimo (copiato da perl) operatore =~ !  :Very Happy: 

Comunque in effetti ho controllato, quell'operatore l'hanno introdotto in bash-3.1, quindi sarebbe meglio eliminarlo per ora...

Ciao

----------

## btbbass

 *Ferdinando wrote:*   

> 
> 
> Comunque in effetti ho controllato, quell'operatore l'hanno introdotto in bash-3.1, quindi sarebbe meglio eliminarlo per ora...
> 
> Ciao

 

Si, confermo, in effetti ho  bash 3.0-r12..

Ora funziona correttamente!!

Grazie

----------

## comio

propongo una feature: inserire due funzioni on_BEGIN e on_END comunque chiamate durante ogni fase (prima e dopo la funzione on_$EBUILD_PHASE). Ho notato che le feauters devono essere impostate praticamente in ogni fase... tanto vale fare un qualcosasa in stile awk.

L'activation di bashrc diventa:

```

##############

# Activation #

##############

# if in debug mode, print phase

debuginfo "step $EBUILD_PHASE"

# sourcing configuration

[[ -r $CONFFILE ]] && source $CONFFILE

# cycling in modules

for mod in ${MODULESDIR}/*.module

do

        # define an empty action

        eval "on_$EBUILD_PHASE () {

                true

        }"

        eval "on_BEGIN() {

                true

        }"

        eval "on_END() {

                true

        }"

        # source the module, if active

        filename=${mod##*/}

        if [ "$(eval echo \$${filename%%.module})" == "on" ]

        then

                source $mod

                # invoke the module-defined action, if any

                on_BEGIN

                on_$EBUILD_PHASE

                on_END

        fi

done

```

mentre il perpackage.module (sempre activation):

```

##############

# Activation #

##############

on_compile() {

export GLOBALCFLAGS=$CFLAGS

package-cflags

        package-nocflags

        einfo Active CFLAGS = $CFLAGS

unset GLOBALCFLAGS

export GLOBALCXXFLAGS=$CXXFLAGS

package-cxxflags

        package-nocxxflags

        einfo Active CXXFLAGS = $CXXFLAGS

unset GLOBALCXXFLAG

export GLOBALLDFLAGS=$LDFLAGS

package-ldflags

        package-noldflags

        einfo Active LDFLAGS = $LDFLAGS

unset GLOBALLDFLAGS

}

on_END() {

export GLOBALFEATURES=$FEATURES

package-features

        package-nofeatures

        einfo Active FEATURES = $FEATURES

unset GLOBALFEATURES

}

```

----------

## Ferdinando

 *comio wrote:*   

> propongo una feature: inserire due funzioni on_BEGIN e on_END comunque chiamate durante ogni fase (prima e dopo la funzione on_$EBUILD_PHASE).

 

Come feature mi piace, dal punto di vista della pulizia del codice e della leggibilità è meglio della soluzione attuale che costringerebbe ad avere del codice fuori dalle funzioni; grazie, magari l'aggiungo in cvs stasera.

Quanto al perpackage non saprei, con la tua soluzione avremmo di nuovo un einfo (o due!) ad ogni passo ed è un po' scocciante; pensavo invece di portare il parsing del file di configurazione fuori delle funzioni, così sarebbe possibile isolare il messaggio "altering xxx" e la scrittura (eventuale) delle flag e delle features dopo la modifica ad una sola fase, ad esempio setup, continuando ad applicare le modifiche a tutte le fasi.

Non è un lavoro particolarmente complesso, anche se non so se lo farò oggi, ma sicuramente prima della prossima release.

Prima della 1.0 (per ora lontana) invece vorrei cercare di semplificare l'architettura di quel modulo, visto che molte funzioni fanno la stessa cosa su variabili diverse. Si vedrà, al momento non ho molto tempo da dedicargli.

Ciao

----------

## Deus Ex

Ciao ragazzi,

volevo segnalarvi un problema che ho avuto con bashrc-ng (o almeno credo sia relativo a quello).

In pratica, volendo ricompilare il mio system, ed essendo in unstable su ~amd64, ho dato un emerge -e system. Nel system, come sapete, ci sono le glibc, le quali, essendo su amd64, ho compilato col supporto sia ai 32 che ai 64 bit.

Ora, avendo compilato gcc nuovo (versione 4.1.1), e volendo compilare le glibc 2.4-r3, questa operazione non mi è riuscita, perchè queste glibc non compilano con CFLAGS="-fPIC", che io ho nel mio make.conf. Allora ho ben pensato di usare la fantastica feature di bashrc-ng "package.cflags", omettendo nel file la suddetta flag. Ma nonostante questa accortezza, la compilazione è lo stesso fallita.

Allora, guardando nel log, mi sono accorto che il problema sorgeva nel momento in cui il compilatore era a 32bit (i686-pc-gnu-linux-gcc) e dava esattamente l'errore riportato in questo post . Quindi ho tolto "-fPIC" dal make.conf, e tutta la compilazione è andata a buon fine.

Dunque, sapendo che bashrc-ng modifica le cflags per il determinato pacchetto in fase di compilazione (dato che ho visto coi miei occhi il warning all'inizio della stessa), ma non compila lo stesso, ho pensato che probabilmente bashrc-ng non riesca a modificare le flags di gcc a 32 bit (mentre a 64 bit lo fa).

Chiedo lumi: la mia supposizione può essere sia corretta? C'è modo di correggere il problema (se c'è?)

Grazie dell'attenzione!  :Very Happy: 

p.s.: ho usato bashrc-ng_beta12

----------

## Dr.Dran

Ciao! Per me dovevi inserire la CFLAG indesiderata nel file "packege.nocflags" dovrebbe funzionare in questo modo:

- package.cflags: inserisce le flags che vogliamo utilizzare nella compilazione al pacchetto

- package.nocflags: elimina e filtra le cflags "generali o di gruppo" che non vogliamo nel pacchetto

Cheers

Franco

P.S. Eventualmente riprova e avvertici se il problema si ripropone  :Very Happy: 

----------

## Deus Ex

Grazie delle indicazioni! In effetti risulta anche più logico inserire le no-flags in quel file, invece che semplicemente ometterle  :Wink: 

Ora però sto ricompilando tutto il world (finito già il system), per cui, prima che io ricompili le glibc, ci vorrà un po'  :Wink: 

----------

## Dr.Dran

 *Deus Ex wrote:*   

> Grazie delle indicazioni! In effetti risulta anche più logico inserire le no-flags in quel file, invece che semplicemente ometterle 
> 
> Ora però sto ricompilando tutto il world (finito già il system), per cui, prima che io ricompili le glibc, ci vorrà un po' 

 

Nessun problema, appena puoi posta  :Very Happy: 

Cheers

Franco

----------

## Ferdinando

 *Deus Ex wrote:*   

> Dunque, sapendo che bashrc-ng modifica le cflags per il determinato pacchetto in fase di compilazione (dato che ho visto coi miei occhi il warning all'inizio della stessa), ma non compila lo stesso, ho pensato che probabilmente bashrc-ng non riesca a modificare le flags di gcc a 32 bit (mentre a 64 bit lo fa).

 

In effetti se quando scrive le Active CFLAGS il -fPIC non c'è non dovrebbe applicarlo. Strano. Io sono su una macchina a 32 bit, ma mi sembra difficile che il problema sia legato a quello, perché in fondo CFLAGS è una variabile abbastanza universale. Può essere un problema di versione del modulo? Appena posso provo a riprodurre il problema.

Ciao

P.S. È vivamente sconsigliato dai dev usare -fPIC, la flag pic è sufficiente per tutti i casi "safe".

----------

## Deus Ex

 *Ferdinando wrote:*   

> 
> 
> P.S. È vivamente sconsigliato dai dev usare -fPIC, la flag pic è sufficiente per tutti i casi "safe".

 

Eeheh! Lo so, ma io ho lo spirito del beta tester  :Wink: 

----------

## Dr.Dran

@Deus Ex

Voglio citare questo articolo sull'hardening di Gentoo che illustra in maniera abbastanza chiara e veloce i vantaggi dell'utilizzo dell'opzione -fpic o -fPIC (sta per Position Indipendent Code), leggilo attentamente e dimmi se questa opzione è veramente necessaria per la tua macchina, in particolare ti cito questa frase che è significativa:

 *Quote:*   

> Why does a normal dynamically linked executable (not position independent shared executable) need no text relocations and PIC addressing? Because the kernel (in a normal world) always moves it to the same location in process memory when started, making it unnecessary for the dynamic loader to address any TEXT relocations in the normal executable: because there are none! We have learned that only shared libraries are located at a given, freely choosen, address space in the process memory of the dynamically linked executable. So, in the text segment of a "fixed load location" normal executable there are no TEXT segment relocations because all addresses are at the same location in memory during every invocation of the program. The addressing of data and functions inside the executable are provided via relative and absolute relocations in a common used set of platform-dependent, performance oriented assembler commands.

 

Anche io utilizzavo questa opzione circa un anno fa, ma ora ho cambiato e utilizzo la flag USE pic perchè viene abilitata dove effettivamente serve ed è safe  :Wink: 

P.S. La mia considerazione anche se è OT l'ho acquisito provando e sperimentando varie configurazioni che mi hanno portato ad utilizzare altri sistemi per avere eseguibili decisamente + performanti  :Very Happy: 

Cheers

Franco

----------

## Deus Ex

Ok, mi hai convinto sul non utilizzo di -fPIC, ma c'è solo una cosa: se do euse -i pic, lui dice:

```
~ $ euse -i pic

global use flags (searching: pic)

************************************************************

[-    ] pic - Build Position Independent Code.  Do not utilize this flag unless you know what you're doing.

```

Ora: sono sicuro che tu sappia cosa fai, ma se viene indicato in questo modo, siamo sicuri che sia "safe"? 

Grazie delle info  :Wink: 

----------

## Dr.Dran

Beh certo poichè viene applicata solo ai programmi che la richiedono   :Wink: 

----------

## .:chrome:.

in ogni caso, quella USE è una di quele da non usare tanto a cuor leggero.

se si vuole un sistema un po' più solito/ostile, a seconda dei punti di vista, è meglio cambiare il profilo, mettere su un hardened, e lasciare fare a lui.

flag come hardened, pie e pic quando vengono impostate dall'utente finiscono solo per fare danni, presto o tardi

----------

## Deus Ex

 *Dr.Dran wrote:*   

> Beh certo poichè viene applicata solo ai programmi che la richiedono  

 

Ehehe! In effetti intendevo se è safe per i soli programmi che la richiedono (visto che è una USE flag  :Wink:  ).

Grazie dei vostri pareri, comunque  :Smile: 

----------

## Al79

Ciao,

installando f-spot, un software instabile presente in portage, sono incappato in questo bug. In particolare il programma ha dei problemi installando

dev-perl/XML-LibXML, qui di seguito posto(in forma limitata) prima l'emerge che usa bashrc-ng e che fallisce e poi l'emerge senza bashrc-ng.

Ciao a tutti 

Alberto

```
Calculating dependencies... done!

>>> Emerging (1 of 16) dev-perl/XML-LibXML-1.58-r1 to /

>>> checking ebuild checksums ;-)

>>> checking auxfile checksums ;-)

>>> checking miscfile checksums ;-)

>>> checking XML-LibXML-1.58.tar.gz ;-)

>>> Unpacking source...

>>> Unpacking XML-LibXML-1.58.tar.gz to /var/tmp/portage/XML-LibXML-1.58-r1/work

 * Applying XML-LibXML-1.58-cleanup.patch ...                                             [ ok ]

>>> Source unpacked.

>>> Compiling source in /var/tmp/portage/XML-LibXML-1.58-r1/work/XML-LibXML-1.58 ...

 * Using ExtUtils::MakeMaker

enable native perl UTF8

running xml2-config...WARNING!

The installed version of libxml2 was not tested with this version of XML::LibXML.

    XML::LibXML may fail building or some tests may not pass.

    Expect strange errors and unstable scripts.

    Check the README file for more informations

END OF WARNING

untested

looking for -lxml2... yes

Checking if your kit is complete...

Looks good

Writing Makefile for XML::LibXML

[..snip..]

/usr/bin/perl5.8.8 /usr/lib/perl5/5.8.8/ExtUtils/xsubpp  -typemap /usr/lib/perl5/5.8.8/ExtUtils/

typemap -typemap typemap  LibXML.xs > LibXML.xsc && mv LibXML.xsc LibXML.c

i686-pc-linux-gnu-gcc -c  -I/usr/include/libxml2 -fno-strict-aliasing -pipe -Wdeclaration-after-

statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -mtune=athlon-xp -march

=athlon-xp -O2 -pipe   -DVERSION=\"1.58\" -DXS_VERSION=\"1.58\" -fPIC "-I/usr/lib/perl5/5.8.8/i6

86-linux/CORE"  -DHAVE_UTF8 -DHAVE_BLANK LibXML.c

In file included from LibXML.xs:11:

ppport.h:362:1: warning: "PERL_UNUSED_DECL" redefined

In file included from LibXML.xs:9:

/usr/lib/perl5/5.8.8/i686-linux/CORE/perl.h:163:1: warning: this is the location of the previous

 definition

In file included from LibXML.xs:32:

/usr/include/libxml2/libxml/DOCBparser.h:22:2: warning: #warning "The DOCBparser module has been

 deprecated in libxml2-2.6.0"

i686-pc-linux-gnu-gcc -c  -I/usr/include/libxml2 -fno-strict-aliasing -pipe -Wdeclaration-after-

statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -mtune=athlon-xp -march

=athlon-xp -O2 -pipe   -DVERSION=\"1.58\" -DXS_VERSION=\"1.58\" -fPIC "-I/usr/lib/perl5/5.8.8/i6

86-linux/CORE"  -DHAVE_UTF8 -DHAVE_BLANK dom.c

i686-pc-linux-gnu-gcc -c  -I/usr/include/libxml2 -fno-strict-aliasing -pipe -Wdeclaration-after-

statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -mtune=athlon-xp -march

=athlon-xp -O2 -pipe   -DVERSION=\"1.58\" -DXS_VERSION=\"1.58\" -fPIC "-I/usr/lib/perl5/5.8.8/i6

[..snip..]

chmod 644 blib/arch/auto/XML/LibXML/LibXML.bs

>>> Source compiled.

>>> Test phase [not enabled]: dev-perl/XML-LibXML-1.58-r1

>>> Install XML-LibXML-1.58-r1 into /var/tmp/portage/XML-LibXML-1.58-r1/image/ category dev-perl

Installing /var/tmp/portage/XML-LibXML-1.58-r1/image/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/

auto/XML/LibXML/LibXML.bs

[..snip..]

Installing /var/tmp/portage/XML-LibXML-1.58-r1/image/usr/lib/perl5/vendor_perl/5.8.8/i686-linux/

XML/LibXML/SAX/Generator.pm

Writing /var/tmp/portage/XML-LibXML-1.58-r1/image//usr/lib/perl5/vendor_perl/5.8.8/i686-linux/au

to/XML/LibXML/.packlist

Appending installation info to /var/tmp/portage/XML-LibXML-1.58-r1/image//usr/lib/perl5/5.8.8/i6

86-linux/perllocal.pod

Can't locate XML/LibXML/SAX/Parser.pm in @INC (@INC contains: /etc/perl /usr/lib/perl5/vendor_pe

rl/5.8.8/i686-linux /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/p

erl5/vendor_perl/5.8.6/i686-linux /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl/5.8.8/i686

-linux /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/5.8.8/i686-linux /

usr/lib/perl5/5.8.8 /usr/local/lib/site_perl .) at /usr/lib/perl5/vendor_perl/5.8.8/XML/SAX.pm l

ine 147.

make: *** [install_sax_driver] Error 2

!!! ERROR: dev-perl/XML-LibXML-1.58-r1 failed.

Call stack:

  ebuild.sh, line 1539:   Called dyn_install

  ebuild.sh, line 1013:   Called src_install

  ebuild.sh, line 1248:   Called perl-module_src_install

  perl-module.eclass, line 152:   Called die
```

```

Calculating dependencies... done!

>>> Emerging (1 of 16) dev-perl/XML-LibXML-1.58-r1 to /

>>> checking ebuild checksums ;-)

>>> checking auxfile checksums ;-)

>>> checking miscfile checksums ;-)

>>> checking XML-LibXML-1.58.tar.gz ;-)

>>> Unpacking source...

>>> Unpacking XML-LibXML-1.58.tar.gz to /var/tmp/portage/XML-LibXML-1.58-r1/work

 * Applying XML-LibXML-1.58-cleanup.patch ...                                             [ ok ]

>>> Source unpacked.

>>> Compiling source in /var/tmp/portage/XML-LibXML-1.58-r1/work/XML-LibXML-1.58 ...

 * Using ExtUtils::MakeMaker

enable native perl UTF8

running xml2-config...WARNING!

The installed version of libxml2 was not tested with this version of XML::LibXML.

    XML::LibXML may fail building or some tests may not pass.

    Expect strange errors and unstable scripts.

    Check the README file for more informations

END OF WARNING

untested

looking for -lxml2... yes

Checking if your kit is complete...

Looks good

Writing Makefile for XML::LibXML

[..snip..]

/usr/bin/perl5.8.8 /usr/lib/perl5/5.8.8/ExtUtils/xsubpp  -typemap /usr/lib/perl5/5.8.8/ExtUtils/

typemap -typemap typemap  LibXML.xs > LibXML.xsc && mv LibXML.xsc LibXML.c

i686-pc-linux-gnu-gcc -c  -I/usr/include/libxml2 -fno-strict-aliasing -pipe -Wdeclaration-after-

statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -mtune=athlon-xp -march

=athlon-xp -O2 -pipe   -DVERSION=\"1.58\" -DXS_VERSION=\"1.58\" -fPIC "-I/usr/lib/perl5/5.8.8/i6

86-linux/CORE"  -DHAVE_UTF8 -DHAVE_BLANK LibXML.c

In file included from LibXML.xs:11:

ppport.h:362:1: warning: "PERL_UNUSED_DECL" redefined

In file included from LibXML.xs:9:

/usr/lib/perl5/5.8.8/i686-linux/CORE/perl.h:163:1: warning: this is the location of the previous

[..snip..]

chmod 755 blib/arch/auto/XML/LibXML/LibXML.so

cp LibXML.bs blib/arch/auto/XML/LibXML/LibXML.bs

chmod 644 blib/arch/auto/XML/LibXML/LibXML.bs

>>> Source compiled.

>>> Test phase [not enabled]: dev-perl/XML-LibXML-1.58-r1

>>> Install XML-LibXML-1.58-r1 into /var/tmp/portage/XML-LibXML-1.58-r1/image/ category dev-perl

/usr/portage/eclass/perl-module.eclass: line 149: test: pure_install: binary operator expected

[..snip..]

XML/LibXML/SAX/Generator.pm

Writing /var/tmp/portage/XML-LibXML-1.58-r1/image//usr/lib/perl5/vendor_perl/5.8.8/i686-linux/au

to/XML/LibXML/.packlist

Appending installation info to /var/tmp/portage/XML-LibXML-1.58-r1/image//usr/lib/perl5/5.8.8/i6

86-linux/perllocal.pod

 * Cleaning out stray man files

>>> Completed installing XML-LibXML-1.58-r1 into /var/tmp/portage/XML-LibXML-1.58-r1/image/

man:

strip: i686-pc-linux-gnu-strip --strip-unneeded

   usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/XML/LibXML/LibXML.so

>>> Merging dev-perl/XML-LibXML-1.58-r1 to /

--- /usr/

--- /usr/lib/

[..snip..]

>>> /usr/share/doc/XML-LibXML-1.58-r1/Changes.gz

 * Man pages are not installed for most modules now.

 * Please use perldoc instead.

>>> Regenerating /etc/ld.so.cache...

```

----------

## Ferdinando

Ho rilasciato la beta13, con i fix per tutti i problemi emersi finora (quello di Al79 dovrebbe essere fixato, fatemi sapere se ricapita). Un altro problemuccio che abbiamo fixato è che con emerge --unmerge non si disinstallava quasi nulla, grazie a CONFIG_PROTECT; i moduli ora sono in /usr/share/portage-bashrc-ng, perciò potete cancellare /etc/portage/bashrc-ng/*.module se volete (NON cancellate /etc/portage/bashrc-ng/bashrc-ng.conf); studieremo qualcosa per permettere la rimozione del bashrc stesso.

Un nuovo modulo, aggiunto sabato, non è stato incluso in questa versione; se qualcuno lo vuole provare lo può prendere da qui; è tratto dall'ennesimo script di Solar, che quando tra le features c'è distclean dovrebbe rimuovere i distfiles usati.

Ciao

P.S. Se avete scaricato l'ebuild prima di ieri sera (21 agosto) vi prego di riscaricarlo, perché (come avrete notato) in caso di update... beh, si cancella da solo  :Mad: 

----------

## Guglie

```
# pwd

/usr/local/portage/overlay/app-portage/portage-bashrc-ng

# ebuild portage-bashrc-ng-0.13_beta.ebuild  digest

/usr/local/portage/overlay/app-portage/portage-bashrc-ng/portage-bashrc-ng-0.1: command not found 4: 

!!! ERROR: app-portage/portage-bashrc-ng-0.13_beta failed.

Call stack:

  ebuild.sh, line 1447:   Called source '/usr/local/portage/overlay/app-portage/portage-bashrc-ng/portage-bashrc-ng-0.13_beta.ebuild'

' portage-bashrc-ng-0.13_beta.ebuild, line 5:   Called inherit 'eutils

  ebuild.sh, line 1182:   Called die

.eclass could not be found by inherit()

!!! If you need support, post the topmost build error, and the call stack if relevant.

aux_get(): (0) Error in app-portage/portage-bashrc-ng-0.13_beta ebuild. (1)

               Check for syntax error or corruption in the ebuild. (--debug

```

pensando a una corruzione dell'ebuild l'ho riscaricato con wget, non era quello

non riesco a capire se quell'errore stia nell'ebuild oppure nell'eclass

----------

## Ferdinando

 *Guglie wrote:*   

> portage-bashrc-ng-0.13_beta.ebuild, line 5:   Called inherit 'eutils

 

La linea dovrebbe essere "inherit eutils"; mi potresti fare un "grep inherit portage-bashrc-ng-0.13_beta.ebuild"?

 *Guglie wrote:*   

> .eclass could not be found by inherit()

 

Se c'è il refuso indicato sopra, questa si spiega perché l'ebuild vorrebbe caricare /usr/portage/eclass/\'eutils.eclass che non esiste; se invece il refuso non c'è e l'apice è stato aggiunto da portage nel segnalare l'errore (probabile visto che preso un mirror a caso la linea è "inherit eutils") allora controlla se esiste /usr/portage/eclass/eutils.eclass; se non esiste o hanno eliminato l'eclass o il tuo portage tree è corrotto. Naturalmente nel primo caso dovremmo capire con cosa l'hanno sostituito.

Ciao

----------

## Dece

Anche io ho lo stesso identico problema, adesso magari provo a rifare un sync.... anche se l'errore strano mi sembra più questo:

```
/usr/local/portage/overlay/app-portage/portage-bashrc-ng/portage-bashrc-ng-0.1: command not found 4:

```

alla peggio lo installo a mano  :Wink: 

Dece

----------

## Kernel78

Io mi sono beccato 

```
>>> checking ebuild checksums ;-)

>>> checking auxfile checksums ;-)

>>> checking miscfile checksums ;-)

>>> checking bashrc-v0.13.tar.gz

!!! Digest verification failed:

!!! /usr/portage/distfiles/bashrc-v0.13.tar.gz

!!! Reason: Filesize does not match recorded size

!!! Got: 9977

!!! Expected: 9017

```

che faccio risinco e incrocio le dita ?

----------

## Ferdinando

 *Dece wrote:*   

> anche se l'errore strano mi sembra più questo:

 In effetti è strano ma non capisco cosa indichi visto che '4:' o '4' nell'ebuild non ci sono,  non so nemmeno perché tagli dal 3 in poi  :Sad:  Forse ebuild è superstizioso...

 *Dece wrote:*   

> alla peggio lo installo a mano 

 Sì, ma poi a che servono gli ebuild?  :Smile:  Il problema è che non ho proprio idea di come riprodurre l'errore.

Ciao

Edit: a Kernel78, riprova a dare il comando digest, quello dovresti generarlo in locale.

----------

## Dece

 *Ferdinando wrote:*   

> In effetti è strano ma non capisco cosa indichi visto che '4:' o '4' nell'ebuild non ci sono,  non so nemmeno perché tagli dal 3 in poi  Forse ebuild è superstizioso...

 

Prima avevo fatto un copia-incolla dal post precedente, ad essere precisi il mio messaggio di errore è questo:

```
bejelit app-portage # ebuild portage-bashrc-ng/portage-bashrc-ng-0.13_beta.ebuild digest

: command not foundapp-portage/portage-bashrc-ng/portage-bashrc-ng-0.13_beta.ebuild: line 4:

```

e mentre provavo a editare con nano l'ebuild per togliere eventuali tab o caratteri strani alla riga 4 (che è vuota), mi sono accorto che a default l'ebuild viene salvato con il fomato DOS: salvandolo in modo normale si sistema tutto  :Smile: 

edit: ho provato a riscaricare l'ebuild sia da firefox che con wget: viene sempre salvato in formato dos

----------

## Ferdinando

 *Dece wrote:*   

> ho provato a riscaricare l'ebuild sia da firefox che con wget: viene sempre salvato in formato dos

 

Capisco, con ogni probabilità è stato caricato con questo formato. Abbiate pazienza, con un po' di fortuna tra non molto !Equilibrium e Philantrop integreranno le patches a cui stanno lavorando e faremo una nuova versione. Purtroppo ora come ora non posso modificare la release, quindi in ogni caso se ne parla nel fine settimana (a meno che !Equilibrium o Dr.Dran non vogliano fixare subito).

Ciao

----------

## FonderiaDigitale

ciao bimbi. era un po' che non partecipavo.

visto che adesso sono in ferie, volevo provare il bisnipote del mio progetto   :Laughing: 

giusto per capire e in 3 parole: cosa c'e' che funziona e cosa NON funziona attualmente?

al di la del fatto che sappiamo tutti che un oggetto di questo genere e' unstable, cosa e' considerabile come non-beta (piu o meno freezed)?

mi metto a gingillare

ciao

----------

## Ferdinando

 *FonderiaDigitale wrote:*   

> ciao bimbi. era un po' che non partecipavo.
> 
> visto che adesso sono in ferie, volevo provare il bisnipote del mio progetto   

 

Woow, chi si rivede! Bentornato  :Very Happy: 

 *FonderiaDigitale wrote:*   

> giusto per capire e in 3 parole: cosa c'e' che funziona e cosa NON funziona attualmente?
> 
> al di la del fatto che sappiamo tutti che un oggetto di questo genere e' unstable, cosa e' considerabile come non-beta (piu o meno freezed)?

 

Uhm... Bella domanda; uno di quelli a cui non mettiamo mano da un po' è proprio il file bashrc-ng/tmpfs.module, che deriva direttamente dal tuo bashrc; se usi l'ebuild (quello sui mirror ha un problemino, vedi su), dovrebbe essere in /usr/share/portage-bashrc-ng.

Ciao e buone ferie!

----------

## Guglie

 *Dece wrote:*   

>  mi sono accorto che a default l'ebuild viene salvato con il fomato DOS: salvandolo in modo normale si sistema tutto 

 

si, convertendolo in unix ha fatto regolarmente il digest anche a me

----------

## Onip

Io ho solamete 256Mb di Ram, dite che posso azzardarmi a provare il modulo tmpfs o è meglio che lasci stare?

eventualmente qualcuno può postare una lista di pacchetti che conosce che richiedono una quantità di Ram maggiore?

Gracias

----------

## Kernel78

 *Onip wrote:*   

> Io ho solamete 256Mb di Ram, dite che posso azzardarmi a provare il modulo tmpfs o è meglio che lasci stare?
> 
> 

 

Se hai abbastanza swap puoi usarlo (ovviamente impostando una dimensione ragiovevole)

----------

## Cazzantonio

non so il perché ma a me il nuovo bashrc non funziona più (non mi monta la tmpfs)

P.S. uso solo il plugin per montare in ram la compilazione

----------

## Kernel78

 *Cazzantonio wrote:*   

> non so il perché ma a me il nuovo bashrc non funziona più (non mi monta la tmpfs)
> 
> P.S. uso solo il plugin per montare in ram la compilazione

 

Anche io uso solo il modulo per tmpfs ma a me funziona bene ...

Hai provato ad abilitare il debug ?

----------

## Ferdinando

 *Cazzantonio wrote:*   

> non so il perché ma a me il nuovo bashrc non funziona più (non mi monta la tmpfs)

 

Ahi. Stai usando la beta13? Il problema non ce l'avevi con il precedente (e quale versione era)?

È mica uscito un nuovo portage di cui non sono a conoscenza? Non synco da lunedì, per cui non ho proprio idea se sia un problema della tua configurazione o è cambiato qualcosa.

@Onip: qui cercavano di fare una stima dei pacchetti che richiedono più spazio, ma non è molto aggiornata (ad esempio gcc-4 a me ha voluto ben più di 500MB). Comunque puoi compensare con lo swap (perdendo in parte i vantaggi) o escludere dal tmpfs un certo numero di pacchetti (soprattutto quelli più monolitici). A occhio la maggior parte dei pacchetti si compila in poco spazio.

Ciao

----------

## Cazzantonio

 *Ferdinando wrote:*   

>  *Cazzantonio wrote:*   non so il perché ma a me il nuovo bashrc non funziona più (non mi monta la tmpfs) 
> 
> Ahi. Stai usando la beta13? Il problema non ce l'avevi con il precedente (e quale versione era)?

 

Prima avevo la 12 e tutto andava liscio...

P.S. potresti mica lasciare su sourceforge le versioni vecchie dello script? In caso di eventi simili...

----------

## Ferdinando

 *Cazzantonio wrote:*   

> P.S. potresti mica lasciare su sourceforge le versioni vecchie dello script? In caso di eventi simili...

 

In realtà non le ho mai tolte, ho solo cambiato i link dalla pagina principale; il tarball del 12 è qui e l'ebuild è qui. Il problema è che il tmpfs non lo tocco da più di un mese, mentre nel bashrc è cambiata solo una variabile che il tmpfs non usa. Ora faccio un webrsync, così passo al portage di ieri e vedo se hanno cambiato qualcosa.

Ciao

----------

## Onip

ho appena provato a cambiare ldflags, ma ho notato una cosa

```
/usr/share/portage-bashrc-ng//perpackage.module: line 241: package-ldflag: command not found
```

Questa riga viene ripetuta diverse volte

```
onip @ Hal9000 ~ $ cat /etc/portage/package.ldflags

x11-terms/gnome-terminal -Wl,-O1 -Wl,--sort-common -Wl,--as-needed

net-im/gaim -Wl,-O1 -Wl,--sort-common -Wl,--as-needed

```

Byez

ps naturalmente sto usando la beta13

----------

## comio

 *Onip wrote:*   

> ho appena provato a cambiare ldflags, ma ho notato una cosa
> 
> ```
> /usr/share/portage-bashrc-ng//perpackage.module: line 241: package-ldflag: command not found
> ```
> ...

 

manca una s alla chiamata alla funzione.

ciao

----------

## Onip

denghiu

----------

## Ferdinando

Dunque: la s mancante la fixo in sourceforge domani, l'ebuild invece è scomparso  :Razz:  Per ora scaricatelo da qui; invece quello nell'overlay di !Equilibrium è sbagliato, ora gli chiedo di aggiornarlo.

Che versione sfigata  :Crying or Very sad: 

----------

## !equilibrium

 *Ferdinando wrote:*   

> ora gli chiedo di aggiornarlo.
> 
> Che versione sfigata 

 

ho aggiornato il repository  :Wink: 

buon sync

----------

## socksz

Salve a tutti,

sembra che questo tool faccia proprio al caso mio, ora vi spiego perche`.

Alcune persone mi avevano avvisato che con Gentoo.. potevo "far fuori" il mio disco rigido e la mia CPU causa le continue compilazioni, eccetera.

Quindi con questo tool, compilando in RAM al posto di usare il disco fisso, lascerei intatto il mio harddisk? Non si rovinerebbe quindi giusto?

Ma, (domanda stupida da un niubbio), come mai l'harddisk si rovina e la RAM no (o la swap? non sta sul disco fisso)?

Riduce anche i tempi di compilazione, fantastico!

Comunque mi interessava sapere le vostre opinioni a riguardo, se mi confermate che la vita del mio harddisk e della mia CPU durerebbero di piu` compilando in RAM  :Wink: 

saluti, e grazie eh!   :Wink: 

----------

## Luca89

 *socksz wrote:*   

> Salve a tutti,
> 
> sembra che questo tool faccia proprio al caso mio, ora vi spiego perche`.
> 
> Alcune persone mi avevano avvisato che con Gentoo.. potevo "far fuori" il mio disco rigido e la mia CPU causa le continue compilazioni, eccetera.
> ...

 

Le tue paure secondo me sono infondate, un hard-disk moderno Ã¨ in grado di resistere all'usura, io ho gentoo su un portatile da ottobre scorso senza compilazione in RAM ed Ã¨ ancora vivo e vegeto, stessa cosa vale per la CPU, se si rompe non devi dare la colpa a gentoo ma a chi ha costruito il portatile. Detto questo, la compilazione in RAM sicuramente da alcuni vantaggi e magari puÃ² servire per placare le tue paure, quindi attivala se ti va. Le schede di memoria RAM sono costruite proprio per immagazzinare dati temporanei, quindi sono sicuramente piÃ¹ veloci e si rovinano di meno con continui I/O. Comunque, ti ribadisco che non Ã¨ fondamentale abilitare la compilazione in RAM, gli hard-disk moderni sono in grado di sopportare anche le compilazioni.

----------

## randomaze

 *socksz wrote:*   

> Ma, (domanda stupida da un niubbio), come mai l'harddisk si rovina e la RAM no (o la swap? non sta sul disco fisso)?

 

A differenza della RAM che é solo elettronica l'hardisk si compone di parti elettroniche e parti meccaniche in movimento.

Non mi é chiaro il ragionamento sulla swap, comuqnue se l'HD si rompe perdi anche la swap, ovviamente.

----------

## socksz

Ok grazie mille per le delucidazioni.

@Luca89:

una curiosita`, ma allora perche` tutti voi non la usate se da` solo vantaggi?

Avete detto che e' piu' veloce, e "allunga" la vita all'harddisk, non capisco perche' non la usiate tutti  :Wink: 

non e' una critica, ma anzi, e' solo una curiosita'  :Very Happy: 

ciao!

@randomaze:

grazie per avermi spiegato per quale motivo la RAM e' piu' "resistente" alle compilazioni   :Wink: 

----------

## Luca89

 *socksz wrote:*   

> @Luca89:
> 
> una curiosita`, ma allora perche` tutti voi non la usate se da` solo vantaggi?
> 
> Avete detto che e' piu' veloce, e "allunga" la vita all'harddisk, non capisco perche' non la usiate tutti 
> ...

 

Io la uso su tutti i miei PC, tranne nel portatile perchÃ© ho poca swap (97Mb) e la RAM non Ã¨ sufficiente per tenere in memoria la compilazione e i dati dei programmi in esecuzione dall'utente. Ti ho detto semplicemente che non Ã¨ indispensabile, ma puoi benissimo usarla.

----------

## Kernel78

La ram è una risorsa più preziosa del hd e non tutti ne hanno a sufficienza per poterne dedicare una parte alla compilazione in ram.

Tra questo e il fatto che magari molti non ne sono nemmeno a conoscenza dovrebbe spiegarti come mai non tutti la usino  :Wink: 

----------

## federico

Ma quanta ram serve per "compilare in ram" ??? Penso una quantita' che probabilmente non tutti possiedono...

Federico

----------

## socksz

1024 MB dite che bastano? Credo di si`..

poi ho una swap di 2 GB.

pero` non mi e` tanto chiaro, il perche`, se finisce la RAM nella compilazione, si passa alla swap, e` sempre sull'hd la swap giusto?

Una curiosita`, per i programmi piu` "grossi" tipo firefox, Xorg, Gnome etc, quanta RAM verrebbe usata?

Grazie ciao, fra poco provo ad installare Xorg con questo metodo   :Very Happy: 

EDIT: posso compilarmi Xorg tramite slackware? Cioe`, compilarlo nel chroot da slackware.. comunque quando ho installato Gentoo, mi chiedevo

se potessi compilare sempre da slackware, cosi` posso lavorare intanto..

----------

## syntaxerrormmm

 *socksz wrote:*   

> 1024 MB dite che bastano? Credo di si`..

 Signori, qui volete sparare a una formica con un bazooka... Ho 512 Mb di RAM, altrettanti di swap e:

```
PORTAGE_MEMSIZE=500M
```

Con X, wmii, Firefox, Sylpheed-claws, CMus, Gaim e tre urxvt in esecuzione eppure xorg-server mi si compila in RAM (quasi) senza swappare... Ah, aggiungo di essere su laptop... Ma l'avete provato prima di giudicare?

 *socksz wrote:*   

> pero` non mi e` tanto chiaro, il perche`, se finisce la RAM nella compilazione, si passa alla swap, e` sempre sull'hd la swap giusto?

 Esatto; quindi, se finisci la RAM swappa e continua a compilare, come avrebbe fatto normalmente.

 *socksz wrote:*   

> Una curiosita`, per i programmi piu` "grossi" tipo firefox, Xorg, Gnome etc, quanta RAM verrebbe usata?

 Firefox, Xorg modulare e (forse) anche GNOME (fino ad un certo punto) si compilano in ram tranquillamente con le mie impostazioni. Trovo invece difficile compilare in RAM le glibc, gcc, OpenOffice-bin e wine. Per questi, ho fatto in modo di impostare la compilazione su HD.

 *socksz wrote:*   

> EDIT: posso compilarmi Xorg tramite slackware? Cioe`, compilarlo nel chroot da slackware.. comunque quando ho installato Gentoo, mi chiedevo se potessi compilare sempre da slackware, cosi` posso lavorare intanto..

 Non capisco bene cosa intendi, però...

----------

## socksz

Intendo che ora sono su slackware, e ho installato Gentoo da qui, seguendo l'handbook (metodo di Installazione alternativa).. insomma ho effettuato

il chroot in /mnt/gentoo, e mi chiedevo se posso emergere Xorg sempre nel chroot, senza riavviare ed andare su Gentoo. Tutto qui`.

ho trovato un errore mentre lanciavo:

```
emerge portage-bashrc-ng
```

dopo aver messo in /etc/portage/package.keywords:

```
app-portage/portage-bashrc-ng ~x86
```

l'errore e`:

```
(chroot) gentoo linux # emerge portage-bashrc-ng

Calculating dependencies... done!

>>> Emerging (1 of 1) app-portage/portage-bashrc-ng-0.13.1_beta to /

>>> checking ebuild checksums ;-)

>>> checking auxfile checksums ;-)

>>> checking miscfile checksums ;-)

>>> checking bashrc-v0.13.tar.gz

!!! Digest verification failed:

!!! /usr/portage/distfiles/bashrc-v0.13.tar.gz

!!! Reason: Filesize does not match recorded size

!!! Got: 9977

!!! Expected: 9017

```

come posso risolvere?

EDIT: qualcuno mi posterebbe gentilmente il suo package.mem? Non ho la minima idea di quanta RAM "assegnare" per installare Xorg, Gnome o quant'altro,

mi farebbe un grosso favore,  :Wink:  grazie!

----------

## Guglie

 *socksz wrote:*   

> 
> 
> ```
> 
> >>> checking bashrc-v0.13.tar.gz
> ...

 

ricrea il digest dell'ebuild, poi riprova a emergerlo

----------

## socksz

 *Guglie wrote:*   

> 
> 
> ricrea il digest dell'ebuild, poi riprova a emergerlo

 

scusa, in che senso?

EDIT: risolto con:

```
emerge --digest portage-bashrc-ng
```

grazie

----------

## socksz

Eccomi ancora..

ehm, a me sembra non funzionare, cioe`, ho emerso portage-bashrc-ng,

ho settato la variabile PORTAGE_MEMSIZE=500M nel mio make.conf

dopodiche` ho dato:

```
# eselect bashrc-ng enable 7
```

per abilitare il tmpfs, ma non sembra compili in RAM.. cioe`, non mi da nessuna informazioni aggiuntiva emerge, ho provato con:

```
# DEBUG=on OVERRIDE_MEMSIZE=10M emerge rdate
```

e riporta:

```
Calculating dependencies... done!

>>> Emerging (1 of 1) net-misc/rdate-1.4-r1 to /

step clean

>>> checking ebuild checksums ;-)

>>> checking auxfile checksums ;-)

>>> checking miscfile checksums ;-)

>>> checking rdate-1.4.tar.gz ;-)

step setup

$PORTAGE_MEMSIZE='500M' defined globally

Overriding $PORTAGE_MEMSIZE with $OVERRIDE_MEMSIZE=10M

 * Mounting /var/tmp/portage/rdate-1.4-r1 of [ 10M ] ...                                                                                                                      [ ok ]

Command line: /bin/mount -o size=10M,mode=770,gid=portage -t tmpfs none /var/tmp/portage/rdate-1.4-r1

step unpack

>>> Unpacking source...

>>> Unpacking rdate-1.4.tar.gz to /var/tmp/portage/rdate-1.4-r1/work

>>> Source unpacked.

step compile

>>> Compiling source in /var/tmp/portage/rdate-1.4-r1/work/rdate-1.4 ...

cc -o rdate rdate.c -O2 -march=prescott -pipe -DINET6

>>> Source compiled.

step test

>>> Test phase [not enabled]: net-misc/rdate-1.4-r1

step install

>>> Install rdate-1.4-r1 into /var/tmp/portage/rdate-1.4-r1/image/ category net-misc

install -d /var/tmp/portage/rdate-1.4-r1/image//usr/bin

install -d /var/tmp/portage/rdate-1.4-r1/image//usr/share/man/man1

install -m 555 rdate /var/tmp/portage/rdate-1.4-r1/image//usr/bin

install -m 444 rdate.1 /var/tmp/portage/rdate-1.4-r1/image//usr/share/man/man1

>>> Completed installing rdate-1.4-r1 into /var/tmp/portage/rdate-1.4-r1/image/

man:

gzipping man page: rdate.1

strip: i686-pc-linux-gnu-strip --strip-unneeded

   usr/bin/rdate

>>> Merging net-misc/rdate-1.4-r1 to /

step preinst

step preinst

--- /etc/

--- /etc/conf.d/

>>> /etc/conf.d/rdate

--- /etc/init.d/

>>> /etc/init.d/rdate

--- /usr/

--- /usr/share/

--- /usr/share/man/

--- /usr/share/man/man1/

>>> /usr/share/man/man1/rdate.1.gz

--- /usr/bin/

>>> /usr/bin/rdate

>>> Safely unmerging already-installed instance...

step prerm

--- !mtime obj /usr/share/man/man1/rdate.1.gz

--- !mtime obj /usr/bin/rdate

--- cfgpro obj /etc/init.d/rdate

--- cfgpro dir /etc/init.d

--- cfgpro obj /etc/conf.d/rdate

--- cfgpro dir /etc/conf.d

--- !empty dir /usr/share/man/man1

--- !empty dir /usr/share/man

--- !empty dir /usr/share

--- !empty dir /usr/bin

--- !empty dir /usr

--- !empty dir /etc

step postrm

step cleanrm

>>> Original instance of package unmerged safely.

step postinst

 * Found temporary portage compile dir (/var/tmp/portage/rdate-1.4-r1), umounting.                                                                                            [ ok ]

rmdir: /var/tmp/portage/rdate-1.4-r1: Directory not empty

>>> Regenerating /etc/ld.so.cache...

>>> net-misc/rdate-1.4-r1 merged.

step clean

>>> No packages selected for removal by clean.

>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.
```

come mai riporta?:

 *Quote:*   

>  * Found temporary portage compile dir (/var/tmp/portage/rdate-1.4-r1), umounting.                                                                                            [ ok ]
> 
> rmdir: /var/tmp/portage/rdate-1.4-r1: Directory not empty

 

cioe`, e` giusto che faccia cosi`? perche` ho lanciato df -h dopo aver finito di compilare e mi da:

```
Filesystem            Size  Used Avail Use% Mounted on

rootfs                9.2G  2.0G  6.8G  23% /

/dev/root             9.2G  2.0G  6.8G  23% /

sysfs                 9.2G  2.0G  6.8G  23% /sys

udev                  443M  2.6M  440M   1% /dev

devpts                443M  2.6M  440M   1% /dev/pts

```

non vedo tmpfs, fate conto che sono su slackware, e sto utilizzando gentoo tramite il chroot /mnt/gentoo /bin/bash..

----------

## syntaxerrormmm

 *socksz wrote:*   

> ho settato la variabile PORTAGE_MEMSIZE=500M nel mio make.conf

 Non mi sembrava fosse da settare in /etc/make.conf... io ce l'ho settata in /etc/portage/bashrc-ng/bashrc-ng...

Ciao.

----------

## socksz

 *syntaxerrormmm wrote:*   

>  *socksz wrote:*   ho settato la variabile PORTAGE_MEMSIZE=500M nel mio make.conf Non mi sembrava fosse da settare in /etc/make.conf... io ce l'ho settata in /etc/portage/bashrc-ng/bashrc-ng...
> 
> Ciao.

 

si la ho settata anche li..

mi potresti postare il tuo /bashrc-ng.conf perfavore?

a qualcun'altro esce quello che ho scritto nel precedente messaggio?

Non so se e' normale.. vorrei vedere se lo e', perche' almeno mi compilo Xorg e Gnome subito con la compilazione in RAM.

Comunque credo che se si mettesse una tabellina di /package.mem con le dimensioni per ogni pacchetto, credo che sarebbe molto utile, ciao!

aspetto il vostro parere   :Wink: 

----------

## Deus Ex

Esce anche a me, ma non mi ha mai dato alcun problema  :Wink: 

Per il package.mem predefinito, se ne era parlato, mi sembra, già qualche tempo fa...   :Confused: 

----------

## socksz

allora, nuove notizie, ho provato ad eseguire:

```
# OVERRIDE_MEMSIZE=10M emerge rdate
```

e da un altro terminale, sempre dentro gentoo ho provato con 'df -h' e riporta:

```
Filesystem            Size  Used Avail Use% Mounted on

rootfs                9.2G  2.0G  6.8G  23% /

/dev/root             9.2G  2.0G  6.8G  23% /

sysfs                 9.2G  2.0G  6.8G  23% /sys

udev                  443M  2.6M  440M   1% /dev

devpts                443M  2.6M  440M   1% /dev/pts

none                   10M  184K  9.9M   2% /var/tmp/portage/rdate-1.4-r1
```

quindi ora sembrerebbe funzionare   :Wink: 

scusate una cosa, ma appena inizia la compilazione, si vede gia` quanto spazio occupa in totale o mano a mano la RAM usata per compilazione aumenterebbe?

Un esempio.. ad esempio, se compilo Xorg, inizialmente mettiamo che prenda 500 MB di RAM.. puo` aumentare arrivando a 700 MB di RAM oppure resta sempre 500 MB?

Di modo che se fosse giusta la seconda opzione, per compilare un pacchetto basterebbe iniziare la compilazione, vedere quanta RAM usa, killare il processo della compilazione

dopodiche` ricompilare usando il giusto OVERRIDE_MEMSIZE.. no?

Com'e` la faccenda?   :Wink: 

EDIT: scusate, come mai con ogni pacchetto mi esce anche:

```
[cut]

>>> Original instance of package unmerged safely.

 * Found temporary portage compile dir (/var/tmp/portage/rdate-1.4-r1), umounting.                                                                        [ ok ]

rmdir: /var/tmp/portage/rdate-1.4-r1: Directory not empty

[cut]
```

sapete perchè?

EDIT-2: scusate, ho provato ad emerge xorg-x11, ma lo ho bloccato con Ctrl+C dopo un po`, ho notato che le partizioni restano montate!

```
# df -h

Filesystem            Size  Used Avail Use% Mounted on

rootfs                9.2G  2.0G  6.8G  23% /

/dev/root             9.2G  2.0G  6.8G  23% /

sysfs                 9.2G  2.0G  6.8G  23% /sys

udev                  443M  2.6M  440M   1% /dev

devpts                443M  2.6M  440M   1% /dev/pts

none                  500M  328K  500M   1% /var/tmp/portage/rdate-1.4-r1

none                  600M  1.7M  599M   1% /var/tmp/portage/libSM-1.0.1

```

come posso risolvere?!

saluti, grazie!  :Cool: 

----------

## Kernel78

Se interrompi la compilazione ti rimane la partizione montata, basta smontarla con umount ...

La dimensione che specifichi è quella massima, la memoria viene allocata dinamicamente fino a quel massimo (es. specifico 1500 mb ma se installo un pacchetto che richiede solo 10 mb vengono allocati solo 10 mb ma se tento di installarne uno da 2000 mb mi darà disk full quando tenta di andare oltre i 1500 mb specificati)

----------

## socksz

 *Kernel78 wrote:*   

> Se interrompi la compilazione ti rimane la partizione montata, basta smontarla con umount ...
> 
> La dimensione che specifichi è quella massima, la memoria viene allocata dinamicamente fino a quel massimo (es. specifico 1500 mb ma se installo un pacchetto che richiede solo 10 mb vengono allocati solo 10 mb ma se tento di installarne uno da 2000 mb mi darà disk full quando tenta di andare oltre i 1500 mb specificati)

 

uhm ok, thanks.

e` sempre normale che quando compila qualcosa.. (ieri compilavo xorg-x11) il processo "cc1plusplus" mi riesce ad occupare addirittura 100% della CPU?

----------

## skypjack

Immagino che la compilazione in RAM non si sposi bene con ccache... Sbaglio?

Sono molto tentato dal provarla...

----------

## Kernel78

 *skypjack wrote:*   

> Immagino che la compilazione in RAM non si sposi bene con ccache... Sbaglio?
> 
> Sono molto tentato dal provarla...

 

Sbagli  :Wink: 

Prova pure, io uso tranquillamente la compilazione in ram e ccache.

----------

## skypjack

Wow...

Usando compilazione in RAM e ccache i tempi di una seconda compilazione saranno più che dimezzati!!!

In pratica, un guadagno che tende all'infinito!!!

Domanda: devo modificare qualcosa per farli coesistere?

Perchè alla compilazione mi sottolinea il fatto che la directory ccache è fuori RAM... ma deve essere, no?

Inoltre, all'atto di smontare, provando ad esempio a ricompilare portage-bashrc-ng, mi dice:

```
rmdir: /var/tmp/portage/portage-bashrc-ng-0.13.1_beta: Directory not empty
```

Why that?

Grazie mille...

----------

## socksz

 *skypjack wrote:*   

> 
> 
> ```
> rmdir: /var/tmp/portage/portage-bashrc-ng-0.13.1_beta: Directory not empty
> ```
> ...

 

Mah.. quello esce sempre anche a me, con ogni pacchetto, credo sia normale, (rivolto ai piu' esperti) e` normale?

PS: scusate, io non ho mai usato ccache, me lo consigliate?

da come ho capito e' un qualcosa che riduce ulteriormente i tempi di compilazione, giusto?

Ma questa riduzione comporta anche degli svantaggi? Grazie, saluti!   :Cool: 

----------

## skypjack

L'unico svantaggio è spazio su disco (impostabile nel limite massimo) occupato in più...

Ma i vantaggi sono, a mio parere, molto soddisfacenti!!

Te lo consiglio...

PS: Allora, il nostro problema comune, è normale o meno? Qualche esperto ci aiuti!!

----------

## socksz

 *skypjack wrote:*   

> L'unico svantaggio è spazio su disco (impostabile nel limite massimo) occupato in più...
> 
> Ma i vantaggi sono, a mio parere, molto soddisfacenti!!
> 
> Te lo consiglio...
> ...

 

Spazio su disco intendi lo spazio occupato per l'installazione di ccache? (che e` una cosa normale)..

intendevo.. col passar del tempo fa qualcosa alla CPU e/o al disco ccache?

Solo una curiosita`   :Wink: 

----------

## skypjack

Con spazio su disco intendo che memorizzando i risultati intermedi di una compilazione essi occupano spazio su disco, appunto...

Una cache, insomma!!

----------

## Ferdinando

 *socksz wrote:*   

> credo sia normale, (rivolto ai piu' esperti) e` normale?

 

Normale è una parola grossa, diciamo che è innocuo; c'è da tempo immemore perché è generato da portage e per risolverlo dovrei leggermi il codice di ebuild.sh se non sbaglio. Ho rimandato la soluzione a quando avrò più tempo; poi se qualcuno ci manda una patch tanto meglio  :Very Happy: 

Ciao

----------

## skypjack

Domanda:

Compilando kdelibs con 500M si è fermato, senza usare swap o altro... Riempiti 500M in var/tmp/portage per kdelibs, fermo!!

Ho aumentato a 750M poi a 900M e via dicendo...

Ma non c'è un modo per dire al programma: "Bello, se riempi lo spazio RAM dedicato, vai sul disco!!"?

Perchè è frustrante, così, credetemi...

----------

## Luca89

 *skypjack wrote:*   

> Domanda:
> 
> Compilando kdelibs con 500M si ï¿½ fermato, senza usare swap o altro... Riempiti 500M in var/tmp/portage per kdelibs, fermo!!
> 
> Ho aumentato a 750M poi a 900M e via dicendo...
> ...

 

Se la RAM si riempie tmpfs usa la swap direttamente, il problema che hai tu dipende dal fatto che hai impostato un MEMSIZE troppo piccolo, metti di default 900M e stai tranquillo.

----------

## Kernel78

se tu hai 1 gb di ram e 2 gb di swap puoi impostare anche 2,5 gb per tmpfs ...

----------

## Ferdinando

 *skypjack wrote:*   

> Ho aumentato a 750M poi a 900M e via dicendo...

 

900MB per kdelibs?!  :Shocked:  OMG! Io l'ho sempre compilato in 500MB; cos'è successo nella r1?

 *skypjack wrote:*   

> Ma non c'è un modo per dire al programma: "Bello, se riempi lo spazio RAM dedicato, vai sul disco!!"?

 

Purtroppo no, perché l'allocazione dei files su disco è gestita dal kernel mentre il programma opera a un livello ben più alto; una cosa che avevo pensato era di forzare la compilazione sul disco la prima volta, monitorare l'occupazione di memoria e poi memorizzarla in un log, e quindi analizzare il log per decidere la quantità di spazio da allocare all'emerge successivo. Il problema è che tutto questo rallenta gli emerge (mentre lo scopo del programma sarebbe l'opposto), e comunque non riuscirebbe a gestire incrementi di 400MB, che sono proprio quelli che uno vorrebbe evitare (il tuo caso o quello di gcc-4).

Ciao

----------

## Luca89

Comunque se a tmpfs si danno 900M di memoria lui non la occupa tutta subito, quindi non vedo il problema. Basta definire come MEMSIZE fisso una dimensione abbastanza alta.

----------

## Kernel78

 *Luca89 wrote:*   

> Comunque se a tmpfs si danno 900M di memoria lui non la occupa tutta subito, quindi non vedo il problema. Basta definire come MEMSIZE fisso una dimensione abbastanza alta.

 

quoto in pieno, io avevo messo molto swap e impostato una dimensione da 1,5 gb in questo modo riuscivo tranquillamente a compilare anche wine ...

----------

## skypjack

Domandona: sto facendo girare portage-bashrc-ng su un sistema contenente dati "sensibili".

Quante sono le possibilità di ritrovarmi con un cucchiaino in mano a raccattare i cocci?

Nel senso, fin quanto è testata e sicura la stabilità di questo programmino?

Grazie...

----------

## cloc3

```

s939 ~ # mount

...

none on /var/tmp/portage/openssl-0.9.8c-r1 type tmpfs (rw,size=1500M,mode=770,gid=250)

none on /var/tmp/portage/wxpython-2.6.3.2 type tmpfs (rw,size=1500M,mode=770,gid=250)

```

come si può immaginare, il mio sistema è prossimo a schiattare.

si tratta del vecchio difetto del programma di fonderia: se un ebuild viene interrotto bruscamente, la ram non viene rilasciata.

non è ancora stata trovata una soluzione per questo?

sarebbe possibile, quantomeno, introdurre un warning, che avvisi l'utente al secondo emerge, della presenza di un mount precedente in /var/tmp/portage, o lo smonti interattivamente ?

oppure si potrebbe aggiungere un'apposita opzione, modificabile nei file di configurazione, che autorizzi portage-bashrc-ng a forzare automaticamente l'umount prima di incominciare il secondo emerge.

----------

## Kernel78

 *skypjack wrote:*   

> Domandona: sto facendo girare portage-bashrc-ng su un sistema contenente dati "sensibili".
> 
> Quante sono le possibilità di ritrovarmi con un cucchiaino in mano a raccattare i cocci?
> 
> Nel senso, fin quanto è testata e sicura la stabilità di questo programmino?
> ...

 

Definisci dati "sensibili" ...

Se sono le tue foto delle vacanze è accettabile ma se sono dati di carte di credito di migliai di clienti la cosa cambierebbe non poco.

----------

## cloc3

 *skypjack wrote:*   

> Domandona: sto facendo girare portage-bashrc-ng su un sistema contenente dati "sensibili".
> 
> 

 

Che centra?

È un normalissimo file bash (==> human readable) che impartisce ad emerge alcune particolari impostazioni di compilazione.

Se le vuoi definire a mano, fai pure.

ma ricordarti di non impostare mai la variabile PORTAGE_TMPDIR di /etc/make.conf nella tua home directory.

----------

## Ferdinando

 *cloc3 wrote:*   

> sarebbe possibile, quantomeno, introdurre un warning, che avvisi l'utente al secondo emerge, della presenza di un mount precedente in /var/tmp/portage, o lo smonti interattivamente ?
> 
> oppure si potrebbe aggiungere un'apposita opzione, modificabile nei file di configurazione, che autorizzi portage-bashrc-ng a forzare automaticamente l'umount prima di incominciare il secondo emerge.

 

Un warning sì, si potrebbe mettere, magari con pausa di 5 secondi per assicurarsi che lo si legga. Il problema della rimozione automatica pone problemi se si emergono due pacchetti contemporaneamente (il secondo cercherebbe di fare le scarpe al primo), e sebbene non inciti gli emerge paralleli, vorrei che il tool continuasse a supportarli. Rendere il tool interattivo non mi piacerebbe, perché sono il primo a lanciare i comandi e andarsene via, e mi girano quando torno e scopro che un programma è in attesa di input da qualche secondo dopo che me ne sono andato.

@skypjack: in una precedente versione era possibile formattarsi l'hard disk creando un ebuild opportuno. Per il momento non c'è nessun bug di questa gravità in giro, ma come sai il batter d'ali di una farfalla in Australia può provocare elezioni anticipate in Italia. Insomma, la risposta è 42: valuta in base alla frequenza dei tuoi backup (se sei superstizioso al tuo oroscopo, se sei religioso a quante buone azioni hai compiuto di recente).

Ciao

----------

## cloc3

 *Ferdinando wrote:*   

> Il problema della rimozione automatica pone problemi se si emergono due pacchetti contemporaneamente 

 

il problema non è solo per le emersioni contemporanee (che rappresentano una pratica suicida, per la quale il difetto potrebbe rivelarsi una protezione), ma piuttosto per le emersioni stoppate bruscamente (per esempio con ctrl-C). Non mi sono capitate ancora compilazioni fallite spontaneamente.

Per questo motivo, l'introduzione di una opzione configurabile ( TMP_RELEASE ???) sarebbe la cosa migliore che mi piace di più. Quando l'opzione viene selezionata esplicitamente, il programma scarica in automatico il mount precedente. Magari avvisando.

 *Ferdinando wrote:*   

> 
> 
> @skypjack: in una precedente versione era possibile formattarsi l'hard disk creando un ebuild opportuno.
> 
> 

 

 :Shocked:   :Shocked:   :Shocked:  Mirabolante. Come avevi fatto?   :Laughing: 

----------

## Ferdinando

 *cloc3 wrote:*   

> il problema non è solo per le emersioni contemporanee (che rappresentano una pratica suicida, per la quale il difetto potrebbe rivelarsi una protezione), ma piuttosto per le emersioni stoppate bruscamente (per esempio con ctrl-C). Non mi sono capitate ancora compilazioni fallite spontaneamente.

 

Immagino tu sia sul ramo stabile, a capita un bug al mese  :Smile:  Sul fatto che sia suicida non sono d'accordo; è da parecchio che non ne faccio ma mi è capitato di voler emergere altre cose mentre aggiornavo openoffice (circa 24ore sul mio vecchio computer, poi sono passato al -bin) e finché portage lo supporta vorrei farlo anch'io. Chiaramente è difficile emergere openoffice in ram, ma l'esempio calzava  :Wink: 

 *cloc3 wrote:*   

> Per questo motivo, l'introduzione di una opzione configurabile ( TMP_RELEASE ???) sarebbe la cosa migliore che mi piace di più. Quando l'opzione viene selezionata esplicitamente, il programma scarica in automatico il mount precedente. Magari avvisando.

 

Sì può fare, magari senza impegno; avviso, aspetto 5 secondi, poi provo l'umount, e se non va vuol dire che c'è un emerge in parallelo. Potrei anche usare fuser per vederlo prima; faccio un paio di test e vedo.

 *cloc3 wrote:*   

>    Mirabolante. Come avevi fatto?  

 

Beh, nel bashrc di Fonderia quando non si riusciva a smontare la dir se ne faceva un "rm -rf"; l'avevo mantenuto, ma nel mio azzerando le opportune variabili il comando poteva essere dato su /.

Ciao

----------

## cloc3

 *Ferdinando wrote:*   

> Sul fatto che sia suicida non sono d'accordo; 

 

il mio sospetto è che, se dovessero capitare in simultanea le operazioni ' Regenerating /etc/ld.so.cache...', possa accadere di tutto.

e se uno dei due emerge prevede una successione di pacchetti piccoli, la probabilità dell'evento potrebbe risultare significativa.

inoltre, potrebbero insorgere problemi di dipendenze incrociate di blocco che gli emerge paralleli finirebbero inesorabilmente per ignorare.

magari ho torto, ma sul tema predico l'astensione.

----------

## The_Paciugo

Ho seguito la guida in prima pagina.

Come posso capire se effettivamente sta compilando in ram o meno ora?

----------

## cloc3

 *The_Paciugo wrote:*   

> Ho seguito la guida in prima pagina.
> 
> Come posso capire se effettivamente sta compilando in ram o meno ora?

 

```

# mount

```

----------

## The_Paciugo

ehm e cosa devo cercare in mount?

ecco cosa l'output mentre sto compilando qualcosa

```
/dev/sda7 on / type reiserfs (rw,noatime,notail)

proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)

udev on /dev type tmpfs (rw,nosuid)

devpts on /dev/pts type devpts (rw,nosuid,noexec)

/dev/sda5 on /boot type reiserfs (rw,noatime,notail)

/dev/sda8 on /home type reiserfs (rw,noexec,nosuid,nodev,noatime,notail)

/dev/hdc1 on /mnt/dati type vfat (rw,nosuid,nodev)

shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)

usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85)

```

----------

## Onip

dovresti avere una riga del tipo

```
none on /var/tmp/portage/pacchetto-versione/
```

Per attivare la compilazione in ram

```
eselect bashrc-ng enable tmpfs
```

E poi devi impostare una quantità di memoria di default in /etc/portage/bashrc-ng/bashrc-ng.conf. Io ho

```
Hal9000 ~ # grep MEM /etc/portage/bashrc-ng/bashrc-ng.conf

# set the PORTAGE_MEMSIZE var below.

PORTAGE_MEMSIZE=500M

```

Byez

----------

## The_Paciugo

none on /var/tmp/portage/koffice-libs-1.5.2 type tmpfs (rw,size=1G,mode=770,gid=250

olè ^^

----------

## comio

Secondo voi se facessimo questa cosa qui:

creare un tmpfs e lo mettessimo in unionfs con una directory del fs, secondo voi sarebbe una buona idea? così da evitere il diskfull? Unionfs gestisce in ogni caso la scrittura su due fs contemporaneamente dando la priorità ad uno (che sarebbe tmpfs)?

accetto commenti!

ciao

luigi

----------

## Onip

sai che ieri ( in coma digestivo, è vero...) mi chiedevo proprio se fosse possibile una cosa del genere, che sarebbe ottima.

----------

## comio

 *Onip wrote:*   

> sai che ieri ( in coma digestivo, è vero...) mi chiedevo proprio se fosse possibile una cosa del genere, che sarebbe ottima.

 

arciderbolina! ancora unionfs non è stato portato al kernel 2.6.18 (sperando che finalmente sia integrato).

ciao

----------

## Luca89

bella l'idea di comio, se portage-bashrc-ng supporterÃ  questa cosa forse abbandonerÃ² /var/tmp montata staticamente in ram.  :Very Happy: 

----------

## The_Paciugo

Avevo usato layman, poi ho disinstallato il tool e l'ho aggiunto al mio overlay in /usr/local/portage/app-portage/portage-bash-rc

Ora per quel che riguarda gli aggiornamenti, devo controllare a mano o c'è qualcosa in portage o nel tool che controlla un'eventuale versione aggiornata?

Inoltre, per quel che riguarda le use flag, ho compilato con tmpfs e resumemerge (quelle che attualmente mi interessano), ma ho dovuto usarle cosi'

```
USE="tmpfs resumemerge" emerge portage-bashrc-ng
```

Per l'overlay non c'è un altro package.use, o una cosa analoga?

----------

## cloc3

 *The_Paciugo wrote:*   

> 
> 
> Per l'overlay non c'è un altro package.use, o una cosa analoga?

 

non serve. le definizioni di /etc/portage si applicano paro paro anche agli ebuild prelevati dall'overlay.

nel tuo caso, poi, le use hanno una utilità limitata.

se tu domani fossi stufo delle tue use e volessi cambiarle, non sarai costretto a reistallare il programma, ma potrai utilizzare eselect, che è stato brillantemente supportato da Ferdinando.

```

# eselect bashrc-ng disable resumemerge

```

----------

## Luca89

 *The_Paciugo wrote:*   

> Ora per quel che riguarda gli aggiornamenti, devo controllare a mano o c'Ã¨ qualcosa in portage o nel tool che controlla un'eventuale versione aggiornata?

 

Se vuoi gli aggiornamenti forse Ã¨ piÃ¹ comodo usare l'overlay che lo sincronizzi tranquillamente tramite layman.

----------

## comio

 *Luca89 wrote:*   

> bella l'idea di comio, se portage-bashrc-ng supporterÃ  questa cosa forse abbandonerÃ² /var/tmp montata staticamente in ram. 

 

L'unico inghippo è che unionfs ancora non è stato portato per il kernel 2.6.18 (che uso...). Ho una specie di codice con il supporto per unionfs... ma aspetto la possibilità di testarlo un attimo.

ciao

----------

## comio

EDIT: Non pare funzionare :S quando il tmpfs si riempe... non viene utilizzato il disco, ma si ha l'errore no space left... anche se con df risulta esserci spazio! 

EDIT2: Ho scritto sulla ml di unionfs... e mi hanno confermato il problema. UnionFS non supporta il "copydown" e la scrittura è fatta solo ed esclusivamente sulla prima directory in scrittura che partecipa all'union. Arciderbolina!

EDIT3: Jan Engelhardt mi ha gentilmente fornito la patch per implementare lo "spreading" delle scritture sui vari branch. A chi è interessato posso fornire una versione modificata dell'ebuild di unionfs...

EDIT4: Ho analizzato la patch... ed è purtroppo "statica" nel senso che in fase di creazione dell'union, cerca il branch con più spazio libero e lo fissa, una volta per tutte, per la scrittura. Quindi non va bene...

Per i temerari... eccovi unionfs+tmpfs:

/usr/share/portage-bashrc-ng/tmpfsunionfs.module

```

# tmpfs module for portage-bashrc-ng

# Distributed under the terms of the GNU General Public License v2

# $Header: /cvsroot/portage-bashrc/portage-bashrc-ng/bashrc-ng/tmpfs.module,v 1.8 2006/07/24 16:54:21 exairetos Exp $

# heavily based on portage-bashrc by Giovanni Ferri <giovanni@fonderiadigitale.it>

# first version by Ferdinando Formica <exairetos@tele2.it> 2006-06-02

# support for UnionFS by Luigi 'Comio' Mantellini <luigi.mantellini@gmail.com> 2006-10-05

# last revision 2006-06-23

# Notice:

#    Without Unionfs support, tmpfs is directly mounted on the $PORTAGE_BUILDDIR directory.

#    With Unionfs support, tmpfs is mounted on $UFS_TMPFSDIR directory and "Disk" direcotory

#    is mounted on $UFS_DISKDIR directory. Then union of $UFS_TMPFSDIR and $UFS_DISKDIR

#    is mounted on $PORTAGE_BUILDDIR.

#########################

# Configuration section #

#########################

# set path for package.mem

MEMFILE=${ROOT}/etc/portage/package.mem

UFS_TMPFSDIR=${UNIONFS_BASETMPFSDIR}/${PF}

UFS_DISKDIR=${UNIONFS_BASEDISKDIR}/${PF}

UFS_ENABLE=${UNIONFS_ENABLE}

#####################

# General utilities #

#####################

# returns 0 if it's mounted, 1 otherwise

check_if_mounted() {

   # grep it in mtab and set $mounted accordingly

   mounteddir="$(mount | \

      grep "none on ${PORTAGE_BUILDDIR} " 2>/dev/null | \

      grep tmpfs 2>/dev/null | tail -n 1)"

   [[ -z "$mounteddir" ]] && return 1

   return 0

}

check_unionfs() {

   unionfs_is_present="$(cat /proc/filesystems | grep unionfs)"

   [[ -z "${unionfs_is_present}" ]] && return 0

   return 1

}

configure_unionfs_support() {

   check_unionfs

   if [ $? -eq 0 ]

   then

      UFS_ENABLE="off"

   else

      if [ "${UNIONFS_ENABLE}" == "on" ]

      then

         UFS_ENABLE="on"

      else

         UFS_ENABLE="off"

      fi

   fi

}

####################

# Mounting section #

####################

# mount the tmpfs dir

mountfs() {

   # get the dimension of the tmpfs filesystem

   evaluate_mem_size

   [[ "$PORTAGE_MEMSIZE" == "0" ]] && return

   # let the user know what we're doing

   ebegin "Mounting ${PORTAGE_BUILDDIR} of [ $PORTAGE_MEMSIZE ]"

      if [ -e ${PORTAGE_BUILDDIR} -a ! -d ${PORTAGE_BUILDDIR} ]

      then

         ewarn "Removing the existing ${PORTAGE_BUILDDIR} as it's not a dir."

            rm -f ${PORTAGE_BUILDDIR}

         eend $?

      fi

   eend $?

   if [ "${UNIONFS_ENABLE}" == "on" ]

   then

      check_unionfs

      if [ $? -eq 1 ]

      then

         einfo "Unionfs support is enabled. Great!"

      else

         ewarn "Unionfs support is not enabled. Check that you have installed correctly the sys-fs/unionfs module."

         ewarn "Continue anyway... without Unionfs support"

      fi

      configure_unionfs_support

   fi

   if [ "${UFS_ENABLE}" == "on" ]

   then

      # With Unionfs Support...

      # ensuring all is correct

      # Portage dir...

      mkdir -p ${PORTAGE_BUILDDIR}

      chown portage:portage ${PORTAGE_BUILDDIR}

      chmod g+w,o-rwx ${PORTAGE_BUILDDIR}

      # Tmpfs directory..

      mkdir -p ${UFS_TMPFSDIR}

      chown portage:portage ${UFS_TMPFSDIR}

      chmod g+w,o-rwx ${UFS_TMPFSDIR}

      # Disk directory...

      mkdir -p ${UFS_DISKDIR}

      chown portage:portage ${UFS_DISKDIR}

      chmod g+w,o-rwx ${UFS_DISKDIR}

      # mounting the tmpfs dir

      /bin/mount -o size=${PORTAGE_MEMSIZE},mode=770,gid=portage -t tmpfs none ${UFS_TMPFSDIR}

      mount -t unionfs -o dirs=${UFS_TMPFSDIR}:${UFS_DISKDIR} none ${PORTAGE_BUILDDIR}

   else

      # Without Unionfs Support...

      # ensuring all is correct

      mkdir -p ${PORTAGE_BUILDDIR}

      chown portage:portage ${PORTAGE_BUILDDIR}

      chmod g+w,o-rwx ${PORTAGE_BUILDDIR}

      # mounting the tmpfs dir

      debuginfo "Command line: /bin/mount -o size=${PORTAGE_MEMSIZE},mode=770,gid=portage -t tmpfs none ${PORTAGE_BUILDDIR}"

      /bin/mount -o size=${PORTAGE_MEMSIZE},mode=770,gid=portage -t tmpfs none ${PORTAGE_BUILDDIR}

   fi

   # warn the user about ccache

   isfeature ccache

   if [ $itsafeature -eq 1 ]

   then

      ewarn "Please remember that ccache data dir is outside the newly mounted"

      ewarn "portage temporary directory, to preserve the spool between merges."

   fi

}

# set in PORTAGE_MEMSIZE the dimension of the tmpfs filesystem

evaluate_mem_size() {

   # if $PORTAGE_MEMSIZE was defined, we have already sourced that

   [[ -n "$PORTAGE_MEMSIZE" ]] && debuginfo "\$PORTAGE_MEMSIZE='$PORTAGE_MEMSIZE' defined  globally"

   # overwrite that if there is a per-package value

   parseconffile "$MEMFILE"

   if [ -n "$configval" ]

   then

      PORTAGE_MEMSIZE=$configval

      debuginfo "\$PORTAGE_MEMSIZE='$PORTAGE_MEMSIZE' defined in $MEMFILE"

   fi

   # overwrite that if the user forced another value

   if [ -n "$OVERRIDE_MEMSIZE" ]

   then

      debuginfo "Overriding \$PORTAGE_MEMSIZE with \$OVERRIDE_MEMSIZE=$OVERRIDE_MEMSIZE"

      PORTAGE_MEMSIZE=$OVERRIDE_MEMSIZE

   fi

   # if there was no value, disable mounting

   [[ -z "$PORTAGE_MEMSIZE" ]] && PORTAGE_MEMSIZE=0

}

# save a backup copy of the dir

savebackup () {

   cd ${PORTAGE_BUILDDIR}/

   tar zcf /tmp/BKUP_${PN}.tar.gz *

   cd - &>/dev/null

}

# restore saved backup

restorebackup () {

   cd ${PORTAGE_BUILDDIR}

   tar zxf /tmp/BKUP_${PN}.tar.gz

   rm /tmp/BKUP_${PN}.tar.gz

   cd - &>/dev/null

}

######################

# Unmounting section #

######################

# unmount the tmpfs dir

unmountfs()

{

   # cycle to get rid of multiple mounts (can it still happen?)

   # or problematic unmountings

   for ((c=0; c<10; c++))

   do

      check_if_mounted

      if [ $? -eq 1 ]

      then

         rmdir ${PORTAGE_BUILDDIR}

         return

      fi

      # let the user know what we're doing

      configure_unionfs_support

      ewarn "Found temporary portage compile dir (${PORTAGE_BUILDDIR}), umounting."

         if [ "${UFS_ENABLE}" == "on" ]

         then

            # unmounting the unionfs directory

            /bin/umount ${PORTAGE_BUILDDIR}

            # unmounting the tmpfs directory

            /bin/umount ${UFS_TMPFSDIR}

            # clean ${UFS_DISKDIR}

            case ${UFS_DISKDIR} in

               /var/tmp/* | /tmp/* )

                  rm -rf --preserve-root ${UFS_DISKDIR}

                  ;;

               * )

                  ewarn "Directory ${UFS_DISKDIR} is not in /var/tmp or /tmp..."

                  ;;

            esac

            

         else

            # unmounting the tmpfs dir

            /bin/umount ${PORTAGE_BUILDDIR}

         fi

         sleep 0.5

      eend $?

   done

   ebegin "Cannot umount tmpfs, erasing contents."

#      rm -rf ${PORTAGE_BUILDDIR}/*

      ewarn "At this point I should remove '${PORTAGE_BUILDDIR}' but I won't :)"

   eend $?

}

##############

# activation #

##############

on_setup () {

   local tmpfsbasedir

   check_if_mounted

   if [ $? -eq 0 ]

   then

      configure_unionfs_support

      if [ "${UFS_ENABLE}" == "on" ]

      then

         tmpfsbasedir=${UFS_TMPFSDIR}

      else

         tmpfsbasedir=${PORTAGE_BUILDDIR}

      fi

         

      dirdim=$(/bin/mount | grep "${tmpfsbasedir}" | sed 's|^.*size=||; s|\,.*$||')

      if [ -z "$dirdim" ]

      then

         ewarn "Error evaluating mounted dimension: leaving ${tmpfsbasedir} as is"

         return

      fi

      # evaluating required partition size

      evaluate_mem_size

      if [ "$dirdim" != "$PORTAGE_MEMSIZE" ]

      then

         # we're remounting

         debuginfo "Command line: /bin/mount -o remount,size=${PORTAGE_MEMSIZE} ${tmpfsbasedir}"

         /bin/mount -o remount,size=${PORTAGE_MEMSIZE} ${tmpfsbasedir}

      else

         # we're resuming a merge

         debuginfo "Leaving '${PORTAGE_BUILDDIR}' mounted"

      fi

   else

      # mounting

      savebackup

      mountfs

      restorebackup

   fi

}

on_install () {

        mkdir -p $WORKDIR

        chown portage:portage $WORKDIR

        chmod 770 $WORKDIR

}

on_postinst () {

   check_if_mounted

   # if it's mounted, then unmount

   if [ $? -eq 0 ]

   then

      isfeature mantain

      if [ $itsafeature -eq 1 ]

      then

         # don't unmount if there's "mantain" in $FEATURES

         einfo "Keeping mounted '${PORTAGE_BUILDDIR}' as requested in \$FEATURES"

         return

      else

         # unmount

         unmountfs

      fi

   fi

}

```

con il relativo file di configurazione (da aggiungere):

/etc/portage/bashrc-ng/bashrc-ng.conf

```

tmpfs=on

UNIONFS_ENABLE=on

UNIONFS_BASEDISKDIR=/var/tmp/portage/unionfs/disk

UNIONFS_BASETMPFSDIR=/var/tmp/portage/unionfs/tmpfs

```

Il codice è assolutamente in beta... ma a me per adesso ha funzionato!

ciao

luigi

----------

## syntaxerrormmm

Avrei una richiesta da fare.

Uso portage-bashrc-ng da tempo e da poco meno utilizzo il meccanismo di ELOG fino a 'info', quindi mi trovo un sacco di entries nella cartella dei log che mi dicono solo che è stata montata la cartella temporanea... E' possibile fare in modo che queste entries non appaiano (a parte disabilitare 'info' in ELOG  :Razz: )?

Ciao, grazie e complimenti per il lavoro.

----------

## syntaxerrormmm

Ciao a tutti,

ho questo problema. Quando emergo un pacchetto che non faccio compilare in RAM (es. gcc), al termine della compilazione mi rimangono tutti i files, sorgenti e compilati (/var/tmp/portage/sys-devel/gcc). Riporto le FEATURES attivate in /etc/make.conf

```
FEATURES="sandbox ccache userpriv usersandbox strict userfetch userpriv collision-protect sfperms"
```

Mi sembra che non ci sia nulla che eviti di pulire la cartella... Come da titolo del post, utilizzo portage-bashrc-ng-0.13.1_beta e portage-2.1.2_rc2-r1.

/etc/portage/bashrc-ng/bashrc-ng.conf:

```
resumemerge=on

localepurge=on

perpackage=on

tmpfs=on

PORTAGE_MEMSIZE=500M
```

/etc/portage/package.mem:

```
sys-devel/gcc 0

www-client/mozilla 0

app-emulation/wine 0

x11-libs/qt 0

sys-libs/glibc 0

app-text/tetex 0

app-office/openoffice-bin 0

www-client/mozilla-firefox 0

x11-libs/wxGTK 0
```

Quello che vorrei è che, al termine della compilazione di questi pacchetti, le directory in /var/tmp/portage venissero cancellate dall'HD (come avviene normalmente quando uso tmpfs per compilare gli altri pacchetti). Sapete aiutarmi?

Ciao.

----------

## .:chrome:.

si potrebbe richiedere che venga aggiunta la funzione che svuota la directory, ma dovrebbe essere fatta con due accorgimenti:

- NON si deve svuotare niente se si vuole poter fare il resume della compilazione

- la rimozione deve essere fatta con un nice molto alto, altrimenti uccide la macchina

----------

## Luca89

Il problema è che il modulo "resumemerge" abilita la feature "keepwork" la quale poi ha l'effetto di non far rimuovere nulla dopo il merge, è su quello che bisogna lavorare.

----------

## randomaze

 *syntaxerrormmm wrote:*   

> Come da titolo del post, utilizzo portage-bashrc-ng-0.13.1_beta e portage-2.1.2_rc2-r1.

 

Ho fatto il merge con il topic di bashrc-ng.

----------

## syntaxerrormmm

 *.:chrome:. wrote:*   

> si potrebbe richiedere che venga aggiunta la funzione che svuota la directory, ma dovrebbe essere fatta con due accorgimenti:
> 
> - NON si deve svuotare niente se si vuole poter fare il resume della compilazione
> 
> - la rimozione deve essere fatta con un nice molto alto, altrimenti uccide la macchina

 Ok, ne farò richiesta, aggiungendo che sarebbe il caso che la directory fosse pulita se e solo se il qmerge sia completato con successo.

O meglio, semplicemente linkerò questo post  :Smile: 

Ciao e grazie a entrambi.

[Edit] Uffi, i mod sono più veloci della luce...  :Razz:  [/Edit]

----------

## comio

Ho un piccolo problema: il modulo tmpfs non mi smonta le directory. Per esempio (ma è una cosa che succede con tutti i pacchetti):

```

 * Found temporary portage compile dir (/var/tmp/portage/sys-fs/fuse-python-0.1-r1), umounting.

umount: /var/tmp/portage/sys-fs/fuse-python-0.1-r1: device occupato

umount: /var/tmp/portage/sys-fs/fuse-python-0.1-r1: device occupato 

```

sto usando la versione 13beta.

Qualche idea?

ciao

luigi

----------

## Onip

Con questa versione

```
[I] app-portage/portage-bashrc-ng (0.13-r1 07/02/2007)
```

Non c'è più (o non viene installato) il modulo per eselect

```

Hal9000 ~ # equery f app-portage/portage-bashrc-ng

[ Searching for packages matching app-portage/portage-bashrc-ng... ]

* Contents of app-portage/portage-bashrc-ng-0.13-r1:

/etc

/etc/portage

/etc/portage/bashrc-ng

/usr

/usr/share

/usr/share/doc

/usr/share/doc/portage-bashrc-ng-0.13-r1

/usr/share/doc/portage-bashrc-ng-0.13-r1/modules

/usr/share/eselect

/usr/share/eselect/modules

/usr/share/portage-bashrc-ng

Hal9000 ~ # ls /usr/share/eselect/modules/

bashcomp.eselect       esd.eselect            kernel.eselect         opengl.eselect         timidity.eselect       

binutils.eselect       java-nsplugin.eselect  mailer.eselect         profile.eselect        

env.eselect            java-vm.eselect        oodict.eselect         rc.eselect  

```

Bug o scelta vostra?

----------

## Onip

Aggiungo che oltre al trascurabile problema di cui sopra, il tool non funziona. Ho avuto bisogno adesso di ri-emergere un paio di cosette e non mi ha montato in ram la tempdir di portage. Nemmeno distclean va, quindi immagino non funzioni nessuno degli altri moduli.

Aiuti, Soluzioni?

Gracias

EDIT: Ho riprovato ad emergerlo e, mi pare, che l'errore stia nell'ebuild. Il file .eselect e i vari .module non vengono proprio installati. Copiandoli a mano tutto quanto funziona

----------

## Luca89

Ho corretto il problema, ora dovrebbe installare tutto, grazie per la segnalazione.  :Wink: 

----------

## Onip

```
Hal9000 ~ # qlist portage-bashrc-ng

/usr/share/doc/portage-bashrc-ng-0.13-r1/modules/tmpfs.gz

/usr/share/doc/portage-bashrc-ng-0.13-r1/modules/resumemerge.gz

/usr/share/doc/portage-bashrc-ng-0.13-r1/modules/per-package.gz

/usr/share/doc/portage-bashrc-ng-0.13-r1/modules/localepurge.gz

/usr/share/doc/portage-bashrc-ng-0.13-r1/modules/distclean.gz

/usr/share/doc/portage-bashrc-ng-0.13-r1/modules/autopatch.gz

/usr/share/eselect/modules/bashrc-ng.eselect

/usr/share/portage-bashrc-ng/tmpfs.module

/usr/share/portage-bashrc-ng/resumemerge.module

/usr/share/portage-bashrc-ng/perpackage.module

/usr/share/portage-bashrc-ng/localepurge.module

/usr/share/portage-bashrc-ng/distclean.module

/usr/share/portage-bashrc-ng/distccval.module

/usr/share/portage-bashrc-ng/autopatch.module

/etc/portage/bashrc-ng/bashrc-ng.conf.example

/etc/portage/bashrc

```

Effettivamente sembra tutto a posto.

Grazie a voi!

----------

## Kernel78

 *comio wrote:*   

> Ho un piccolo problema: il modulo tmpfs non mi smonta le directory. Per esempio (ma è una cosa che succede con tutti i pacchetti):
> 
> ```
> 
>  * Found temporary portage compile dir (/var/tmp/portage/sys-fs/fuse-python-0.1-r1), umounting.
> ...

 

Anche a me da lo stesso problema da quando ho aggiornato a portage-2.1.2-r9 (questa mattina), ho notato che disabilitando tmpfs mi rimangono le varie directory in /var/tmp/portage ...

Idee/suggerimenti/consigli/proposte/soluzioni ?

----------

## !equilibrium

 *Kernel78 wrote:*   

> Anche a me da lo stesso problema da quando ho aggiornato a portage-2.1.2-r9 (questa mattina), ho notato che disabilitando tmpfs mi rimangono le varie directory in /var/tmp/portage ...

 

ci sto lavorando proprio in questo momento.

il nuovo portage crea una struttura di dir in /var/tmp/portage completamente diversa rispetto alla versione precedente. appena risolvo vedo di rilasciare tutto quanto (compresa la nuova versione del modulo 'tmpfs') in overlay.

/EDIT:

ho risolto il problema e ho fatto pure il bump version della nuova release sul GeCHI Overlay.

# layman -s gechi

# emerge -av portage-bashrc-ng

in caso riscontriate problemi o altro, vi pregherei di fare un bugreport sul tracker del progetto anzichè scrivere qui sul sito, grazie  :Wink: 

buon emerge a tutti.

p.s.: il sito del GeCHI Overlay

----------

## comio

 *!equilibrium wrote:*   

> 
> 
> /EDIT:
> 
> ho risolto il problema e ho fatto pure il bump version della nuova release sul GeCHI Overlay.
> ...

 

work fine!

thanks.

luigi

----------

## cloc3

 *comio wrote:*   

> 
> 
> work fine!
> 
> 

 

 :Rolling Eyes: 

http://sourceforge.net/tracker/?atid=879268&group_id=176946&func=browse

2 in un colpo

 :Laughing:   :Laughing:   :Laughing: 

----------

## topper_harley

 *!equilibrium wrote:*   

> 
> 
> ho risolto il problema e ho fatto pure il bump version della nuova release sul GeCHI Overlay.
> 
> # layman -s gechi
> ...

 

L'overlay non è più in layman?

```
caffeine ~ # layman --list | grep gechi

caffeine ~ # 

```

----------

## cloc3

 *topper_harley wrote:*   

> 
> 
> L'overlay non è più in layman? 
> 
> 

 

leggi bene le istruzioni sul sito dei gechi.

e in particolare il punto 2. :

 *Quote:*   

> 
> 
> Now it's time to download/update the list of available overlays and add the GeCHI Overlay. To do this, simply run this command: 
> 
>  # layman -f -o http://gechi-overlay.sf.net/layman.xml -a gechi 
> ...

 

----------

## Gitanovic

Ehm... seguendo le istruzioni:

```

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

* Running command "/usr/bin/svn co https://svn.sourceforge.net/svnroot/gechi-overlay/overlay// /usr/portage/local/layman/gechi"...

svn: richiesta PROPFIND fallita su '/svnroot/gechi-overlay/overlay'

svn: PROPFIND di '/svnroot/gechi-overlay/overlay': SSL negotiation failed: SSL disabled due to library version mismatch (https://svn.sourceforge.net)

* Failed to add overlay "gechi".

* Error was: Adding the overlay failed!

```

non mi funziona ... why:?:

----------

## !equilibrium

 *Gitanovic wrote:*   

> non mi funziona ... why:?:

 

SF è andato in timeout, aspetta qualche minuto e poi riprova.

 *cloc3 wrote:*   

> 2 in un colpo
> 
>   

 

1 solo (che era già noto e risolto in CVS), mentre l'altro è un bogus  :Wink: 

p.s.: tempo di finire un paio di test, creare il nuovo tarball, darlo in pasto a SF e poi aggiorno l'overlay alla versione 0.14.1

----------

## Gitanovic

Veramente ho provato già molte volte... comunque il problema non mi sembra un timeout:

```

svn: PROPFIND di '/svnroot/gechi-overlay/overlay': SSL negotiation failed: SSL disabled due to library version mismatch (https://svn.sourceforge.net)

```

 :Confused: 

----------

## !equilibrium

 *Gitanovic wrote:*   

>  

 

ho appena rimosso e aggiunto l'overlay in locale e ha funzionato:

```
notebook portage-bashrc-ng # layman -d gechi

* Successfully deleted overlay "gechi".

notebook portage-bashrc-ng # layman -f -o http://gechi-overlay.sf.net/layman.xml -a gechi

* Running command "/usr/bin/svn co https://svn.sourceforge.net/svnroot/gechi-overlay/overlay// /usr/portage/local/layman/gechi"...

 [ .. SNIP .. ]

Checked out revision 75.

* Successfully added overlay "gechi".
```

io sto usando la versione di layman 'stable' di portage, tu quale versione stai usando?

----------

## Gitanovic

Io sto usando la versione app-portage/layman-1.0.6  ovvero la stable

riscontravo il problema che non mi smontava le directory... quindi ho provato ad aggiornare layman... e mi ha dato l'errore di sopra

ho anche provato a togliere gli overlays che avevo... col solo risultato che ora non li riesco a rimettere   :Shocked: 

Comunque per ora non è un grosso problema, alla fine di ogni emerge smonto tutto a manina

P.S. ho appena riprovato 

```

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

* Running command "/usr/bin/svn co https://svn.sourceforge.net/svnroot/gechi-overlay/overlay// /usr/portage/local/layman/gechi"...

svn: richiesta PROPFIND fallita su '/svnroot/gechi-overlay/overlay'

svn: PROPFIND di '/svnroot/gechi-overlay/overlay': SSL negotiation failed: SSL disabled due to library version mismatch (https://svn.sourceforge.net)

* Failed to add overlay "gechi".

* Error was: Adding the overlay failed!

```

----------

## Kernel78

 *Gitanovic wrote:*   

> Io sto usando la versione app-portage/layman-1.0.6  ovvero la stable
> 
> riscontravo il problema che non mi smontava le directory... quindi ho provato ad aggiornare layman... e mi ha dato l'errore di sopra
> 
> ho anche provato a togliere gli overlays che avevo... col solo risultato che ora non li riesco a rimettere  
> ...

 

Visto che evidentemente hai qualche problema con layman dovresti aprire una nuova discussione, qui sei un po' OT.

----------

## Gitanovic

No, mi sono espresso male... ho eliminato gli overlay gechi-stable e gechi-testing (quelli che avevo) e non riesco a rimetterli.

Infatti ho appena fatto la prova del 9... ho installato con successo l'overlay "sunrise", quindi il problema non è layman.

EDIT:

Ho dato uno sguardo al file: "/usr/portage/local/layman/cache_65bd38402ac8431067b54904bd2ed2d1.xml"

ed ho notato che il campo "src" ha uno "/" alla fine di ogni overlay

mentre nel file "/usr/portage/local/layman/cache_65bd38402ac8431067b54904bd2ed2d1.xml"

il campo src non ha mai uno "/" alla fine di ogni overlay...

magari potrebbe essere questo il problema

----------

## !equilibrium

 *Gitanovic wrote:*   

> No, mi sono espresso male... ho eliminato gli overlay gechi-stable e gechi-testing (quelli che avevo) e non riesco a rimetterli.

 

"gechi-testing" e "gechi-stable" sono un alias di "gechi", puoi fare a meno di aggiungerli.

sono rimasti solo per BC, ma entrambi puntano al repository "gechi".

----------

## Gitanovic

Ehm... io non riesco ad installare ne gechi, ne gechi-stable, ne gechi-testing   :Confused: 

p.s. (ho fatto un edit sopra)

----------

## !equilibrium

portage-bashrc-ng v0.14.1 ora è in overlay

questa versione risolve il problema di eselect che non funzionava adeguatamente, ed è stato deprecato l'uso del file bashrc-ng.conf per l'attivazione/disattivazione dei moduli in favore di eselect.

i cambiamenti dalla versione 0.13 all'attuale sono chilometrici e purtroppo non ho tempo per riassumerli tutti quanti sul forum (in caso leggete il Changelog). velocemente vi posso anticipare che:

- ho fixato quintalate di bugs

- i moduli si gesticono tramite eselect

- il modulo tmpfs è in grado di rilevare un precedente emerge interrotto e risistemare la PORTAGE_TMPDIR come vuole portage.

- il modulo tmpfs calcola automaticamente il size dei mount point TMPFS, quindi niente più problemi dovuti all'uso errato di PORTAGE_MEMSIZE (che è deprecato ed esclusivo del modulo 'oldtmpfs') e niente più "blocchi misteriosi e freeze del sistema" (e relativi bugreports per la gioia dei devel).

- il modulo tmpfs è un po più "prolisso" del normale, così l'utonto... emh l'utente finale comprende meglio quello che sta facendo bashrc senza dover estrarre la sfera magica e consultare gli oracoli.

- bashrc ora dovrebbe funzionare anche su G/fBSD

a breve arriverà una nuova release che prevederà:

- documentazione ufficiale via "man" (naturalmente è aggiornata)

- il file bashrc-ng.conf scomparirà del tutto in favore di moduli appositi di eselect (per la gioia di grandi e piccini niente più file da editare!)

- il tmpfs sarà in grado di rilevare processi multipli di merge interrotti (per la gioia dei devel che scrivono/testano ebuild in concomitanza di bashrc-ng) e fixarli (l'hack è già disponibile, devo solo fare il commit in CVS)

- varie ed eventuali (chi vuole proporre nuove feature può farlo tranquillamente tramite il tracker di SF)

 *Gitanovic wrote:*   

> mentre nel file "/usr/portage/local/layman/cache_65bd38402ac8431067b54904bd2ed2d1.xml"
> 
> il campo src non ha mai uno "/" alla fine di ogni overlay...
> 
> magari potrebbe essere questo il problema

 

mmmmmm... non credo sia questo il problema, perchè altre persone riescono tranquillamente a fare il sync, ciò non toglie che si possa tentare la tua soluzione (non sia mai che tu abbia scovato un bug di layman); purtroppo ora il server di accesso ssh/ftp di sourceforge è offline, appena torna su vedo di togliere lo slash finale dal file xml del gechi-overlay.

----------

## Gitanovic

Ce l'ho fatta...   :Very Happy:   :Very Happy:   :Very Happy: 

Il problema era la libreria SSL

infatti ho abilitato le USE expat e sock5 ed ho dato emerge -DuN net-misc/neon

al termine sono riuscito ad installare l'overlay  :Wink: 

----------

## sanzo77

Sto ricercando il topic per eseguire la compilazione in ram, ma con il motore di ricerca faccio fatica a trovarlo, qualcuno si e' salvato il link?

----------

## MeMyselfAndI

cerca portage-bashrc-ng oppure tra la documentazione in italiano (3 subforum italiano)

----------

## crisandbea

 *sanzo77 wrote:*   

> Sto ricercando il topic per eseguire la compilazione in ram, ma con il motore di ricerca faccio fatica a trovarlo, qualcuno si e' salvato il link?

 

cerchi questo https://forums.gentoo.org/viewtopic-t-297692-highlight-ram.html

oppure questo https://forums.gentoo.org/viewtopic-t-523830-highlight-ram.html

o ancora questo https://forums.gentoo.org/viewtopic-t-469501-highlight-portagebashrcng.html

ciaoLast edited by crisandbea on Fri Feb 23, 2007 10:05 am; edited 1 time in total

----------

## sanzo77

Grazie a tutti, cercavo proprio portage-bashrc-ng   :Smile: 

----------

## gutter

[MOD]Fatto il merge del thread di sanzo77 con questo.[/MOD]

----------

## cloc3

qui

 *equilibrium! wrote:*   

> 
> 
>  fai una richiesta di feature direttamente sul tracker del progetto SF, cosi' le implementiamo.
> 
> 

 

done

 :Embarassed:   :Embarassed:  naturalmente, sono riuscito a sbagliare il posto, ma che ci vuoi fare, prendetemi così.

----------

## Scen

Ho sempre letto di questo insieme di strumenti ma non l'avevo ancora utilizzato!

Devo pagare un pò di birre a voi devs di bashrc-ng.... il modulo perpackage è proprio quello che mi serviva  :Cool: 

Comunque, volevo segnalare che, quando lancio un emerge, mi viene fuori, tra i vari messaggi iniziali

```

/usr/share/portage-bashrc-ng//perpackage.module: line 176: [: -eq: unary operator expected

```

se può servire, questo è il mio emerge --info:

```

Portage 2.1.2.2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r5 x86_64)

=================================================================

System uname: 2.6.19-gentoo-r5 x86_64 AMD Athlon(tm) 64 Processor 3800+

Gentoo Base System release 1.12.9

Timestamp of tree: Wed, 14 Mar 2007 17:20:01 +0000

distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]

ccache version 2.4 [enabled]

dev-java/java-config: 1.3.7, 2.0.31

dev-lang/python:     2.4.3-r4

dev-python/pycrypto: 2.0.1-r5

dev-util/ccache:     2.4-r6

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.13, 2.61

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10

sys-devel/binutils:  2.16.1-r3

sys-devel/gcc-config: 1.3.14

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.17-r2

ACCEPT_KEYWORDS="amd64"

AUTOCLEAN="yes"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=k8 -O2 -pipe"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php4/ext-active/ /etc/php/apache2-php4/ext-active/ /etc/php/cgi-php4/ext-active/ /etc/php/cli-php4/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo"

CXXFLAGS="-march=k8 -O2 -pipe"

DISTDIR="/var/tmp/distfiles"

FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict"

GENTOO_MIRRORS="http://gentoo.inode.at/ http://mirror.switch.ch/ftp/mirror/gentoo/ http://gentoo.tiscali.nl/ http://gentoo.supp.name/ http://gentoo.ynet.sk/pub"

LANG="it_IT.UTF-8"

LC_ALL="it_IT.UTF-8"

LINGUAS="it"

MAKEOPTS="-j2"

PKGDIR="/var/tmp/packages"

PORTAGE_RSYNC_EXTRA_OPTS="--progress"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/sunrise /usr/portage/local/layman/liquidx /usr/portage/local/layman/voip /usr/portage/local/layman/gechi"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

USE="X alsa amd64 berkdb bitmap-fonts cdr cli cracklib crypt cups dbus dri dv dvd dvdr eds emboss encode fam firefox flac fortran gif gpm gtk2 hal iconv isdnlog jpeg kde kdeenablefinal kdehiddenvisibility libg++ midi mp3 mpeg ncurses nls nptl nptlonly ogg opengl pam pcre perl png ppds pppd python qt3 quicktime readline reflection sdl session spell spl ssl tcpd theora tiff truetype truetype-fonts type1-fonts unicode usb vorbis xml xorg zlib" ALSA_CARDS="via82xx" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse penmount" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="it" USERLAND="GNU" VIDEO_CARDS="fbdev nv nvidia vesa"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS

```

----------

## !equilibrium

 *Scen wrote:*   

> 
> 
> ```
> 
> /usr/share/portage-bashrc-ng//perpackage.module: line 176: [: -eq: unary operator expected
> ...

 

per cortesia saresti cosi' gentile da fare la segnalazione del problema sul tracker del progetto SF?

appena ho un po di tempo ci butto un occhio e risolvo il tuo problema. grazie per la tua segnalazione  :Wink: 

----------

## 102376

ho installato senza nessun problema, 

poi ho configurato sto file /etc/portage/bashrc-ng/bashrc-ng.conf

mettendo quanta ram volevo , ma poi non devo fare altro??

basta che do emerge nome pacchetto?? o devo configurare altri file??

ora sto compilando kdelibs

e con un bel mount ho 

```

/dev/sda3 on / type ext3 (rw,noatime)

proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)

udev on /dev type tmpfs (rw,nosuid)

devpts on /dev/pts type devpts (rw,nosuid,noexec)

/dev/sda4 on /home type ext3 (rw,noatime)

/dev/sdb2 on /mnt/dati type ext3 (rw,noatime)

shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)

usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85)

none on /var/tmp/portage/media-libs/xine-lib-1.1.4-r2 type tmpfs (rw,size=800M,mode=770,gid=250)

none on /var/tmp/portage/kde-base/kdelibs-3.5.5-r10 type tmpfs (rw,size=800M,mode=770,gid=250)

```

----------

## crisandbea

ragazzi sapete dirmi se questa procedura è aggiornata??? o meglio se va ancora bene oppure devo guardare il sito dei gechi per caricare layman ed il relativo tool per compilare in ram???

ciauz

----------

## !equilibrium

 *zocram wrote:*   

> ho installato senza nessun problema,
> 
> poi ho configurato sto file /etc/portage/bashrc-ng/bashrc-ng.conf

 

non funziona così portage-bashrc-ng, non c'è più da specificare la dimensione della RAM.

che versione stai usando di portage-bashrc-ng?

 *zocram wrote:*   

> ora sto compilando kdelibs
> 
> e con un bel mount ho 
> 
> none on /var/tmp/portage/media-libs/xine-lib-1.1.4-r2 type tmpfs (rw,size=800M,mode=770,gid=250)
> ...

 

da quello che sto vedendo qui, non stai usando l'ultima versione (v0.14.2) di portage-bashrc-ng

----------

## !equilibrium

 *crisandbea wrote:*   

> ragazzi sapete dirmi se questa procedura è aggiornata??? o meglio se va ancora bene oppure devo guardare il sito dei gechi per caricare layman ed il relativo tool per compilare in ram???

 

non ho capito cosa intendi dire.

----------

## 102376

ok ok ho trovato, ho installato la nuova versione e usato eselect per usare la compilazione in ram!

ma poi ho settato ugualmente nel /etc/portage/bashrc-ng/bashrc-ng.conf la dim 

sbaglio?? come faccio a decidere quanta mem usare??

----------

## !equilibrium

 *zocram wrote:*   

> ma poi ho settato ugualmente nel /etc/portage/bashrc-ng/bashrc-ng.conf la dim 
> 
> sbaglio?? come faccio a decidere quanta mem usare??

 

non serve, la dimensione della shared memory è calcolata in automatico ad ogni emerge.

----------

## crisandbea

 *!equilibrium wrote:*   

>  *crisandbea wrote:*   ragazzi sapete dirmi se questa procedura è aggiornata??? o meglio se va ancora bene oppure devo guardare il sito dei gechi per caricare layman ed il relativo tool per compilare in ram??? 
> 
> non ho capito cosa intendi dire.

 

intendo dire che se la procedura descritta nella prima pagina ovvero:

```

# emerge layman

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

# layman -f -o http://wtk-overlay.sf.net/layman.xml -a WTK-Testing
```

è sempre la stessa oppure bisogna cambiare qualcosa.

ciauz

----------

## !equilibrium

 *crisandbea wrote:*   

> intendo dire che se la procedura descritta nella prima pagina ovvero:
> 
> è sempre la stessa oppure bisogna cambiare qualcosa.

 

grazie per la segnalazione!

le informazioni riportate sono vecchie e deprecate da una vita oramai, tra l'altro la cosa era già stata segnalata a @Ferdinando a suo tempo, il quale si era incaricato di modificarle ed aggiornale. ad oggi pare che ciò non sia avvenuto, pazienza, ho provveduto a sistemare il primo post (ora capisco il perchè molte persone sul chan IRC #gentoo-it lamentano grossi problemi con il tool e usano ancora versioni vecchie, d'oh!).

p.s.: per fine mese dovrebbe essere pronta la versione 0.15, pazientate ancora un poco --> Tasks List

----------

## flocchini

io ancora non capisco che istruzioni dovrei seguire... Il primo post della discussione e' stato modificato a settembre, e riporta ancora la specificazione della dimensione del ramdisk nel .conf... E il sito dei gechi sezione "project" ha la sezione relativa vuota   :Exclamation:   help   :Wink: 

----------

## !equilibrium

 *flocchini wrote:*   

> io ancora non capisco che istruzioni dovrei seguire... Il primo post della discussione e' stato modificato a settembre, e riporta ancora la specificazione della dimensione del ramdisk nel .conf...

 

ho fixato anche questo nel post iniziale.

non c'è nulla da impostare, si attiva il plugin con eselect e basta.

l'utente non deve specificare manualmente nessuna opzione perchè non ce n'è bisogno, sarà il plugin stesso a fare le dovute scelte in modo del tutto trasparente all'utente finale.

 *flocchini wrote:*   

> E il sito dei gechi sezione "project" ha la sezione relativa vuota    help  

 

i GeCHI non possono farci nulla, sono gli sviluppatori iniziali del tool che non hanno mai documentato una fava e/o se lo hanno fatto hanno prodotto solo documentazione parziale ed errata (vedi sito web originale del progetto, questo thread, quello sul forum internazionale) e attualmente hanno abbandonato il progetto. Abbi/abbiate pazienza fino alla versione 0.15 dove ho creato tutta la documentazione man per ogni cosa, e la relativa documentazione online aggiornata la quale verrà resa pubblica con l'uscita della nuova release.

----------

## flocchini

grazie. Cmq figurati, nessuna fretta ci mancherebbe, era solo per avere un po' di ordine  :Wink: 

----------

## crisandbea

come mai ho questo errore:

```

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

* Running command "/usr/bin/svn co "https://svn.sourceforge.net/svnroot/gechi-overlay/overlay//" "/usr/portage/local/layman/gechi""...

svn: error: cannot set LC_ALL locale

svn: error: environment variable LC_ALL is it_IT it_IT@euro

svn: error: please check that your locale name is correct

* Failed to add overlay "gechi".

* Error was: Adding the overlay failed!

```

le variabili sono settate, infatti non capisco il perchè mi dia quell'errore.     

ovviamente ho seguito la guida alla localizzazione all'atto dell'installazione.

ciao

EDIT:risolto  dando un 

```
export LC_ALL=it_IT
```

scusate il ritardo nell'esporvi la soluzione, ma sono stato impegnato.

ciauz

----------

## skypjack

Volevo mettere su portage-bashrc-ng, che usavo qualche tempo fa, prima che il mio disco facesse ciao con la manina.

Nel primo post si dice di seguire la documentazione sul sito dei gechi, ma come notato anche due post sopra questa non esiste per cause di forza maggiore.

La domanda sorge spontanea: a chi mi devo appellare per installare portage-bashrc-ng?

Aspetto fiducioso e impaziente...

----------

## !equilibrium

 *skypjack wrote:*   

> Volevo mettere su portage-bashrc-ng, che usavo qualche tempo fa, prima che il mio disco facesse ciao con la manina.
> 
> Nel primo post si dice di seguire la documentazione sul sito dei gechi, ma come notato anche due post sopra questa non esiste per cause di forza maggiore.
> 
> La domanda sorge spontanea: a chi mi devo appellare per installare portage-bashrc-ng?
> ...

 

non vedo quali siano i problemi di installazione.

sul sito dei gechi le istruzioni di installazione ci sono.

----------

## skypjack

Scusami, ma non le ho trovate proprio (premetto che sono in periodo di esami quindi il mio cervello 􏻨 rallentato del 50%)...

----------

## !equilibrium

 *skypjack wrote:*   

> Scusami, ma non le ho trovate proprio (premetto che sono in periodo di esami quindi il mio cervello 􏻨 rallentato del 50%)...

 

al primo post di questo thread c'è una scritta in rosso a caratteri cubitali che riporta un link

----------

## skypjack

 *!equilibrium wrote:*   

> 
> 
> al primo post di questo thread c'è una scritta in rosso a caratteri cubitali che riporta un link
> 
> 

 

Gentilissimo, grazie, chiudiamo qua.

Tengo a farti notare che non ho scritto "sono ottuso, come scarico il programma", ma ho chiesto dove potevo trovare info sulla installazione e configurazione di quest'ultimo. Il passaggio tramite overlay e l'emerge del pacchetto direi che sono abbastanza ovvi, ma grazie lo stesso...

Bastava dire: non esiste.

Passo e chiudo.

----------

## !equilibrium

 *skypjack wrote:*   

> Tengo a farti notare che non ho scritto "sono ottuso, come scarico il programma", ma ho chiesto dove potevo trovare info sulla installazione e configurazione di quest'ultimo. Il passaggio tramite overlay e l'emerge del pacchetto direi che sono abbastanza ovvi, ma grazie lo stesso...
> 
> Bastava dire: non esiste.
> 
> Passo e chiudo.

 

e io tengo a precisare che la tua richiesta è stata per la sola installazione, mentre per la documentazione sei perfettamente a conoscienza che non esiste per causa di forza maggiore:

 *skypjack wrote:*   

> Nel primo post si dice di seguire la documentazione sul sito dei gechi, ma come notato anche due post sopra questa non esiste per cause di forza maggiore. La domanda sorge spontanea: a chi mi devo appellare per installare portage-bashrc-ng?

 

lo hai scritto tu, io non ho la sfera di cristallo.

hai chiesto aiuto per "l'installazione" e ti ho risposto di conseguenza.

ripeto: le informazioni per la configurazione non esistono perchè chi ha scritto i moduli per portage-bashrc-ng ha pensato bene di non farlo e se lo ha fatto non l'ha tenuta aggiornata con il passare del tempo. in generale la vecchia documentazione dovrebbe ancora andare bene, fatta eccezione per il modulo tmpfs che non richiede nessun tipo di settagio, quindi non serve nemmeno la conf.

----------

## Tigerwalk

Scusate la profonda ignoranza in materia, se voglio compilare in memoria quindi, devo attivare il modulo tmpfs (anche oldtmpfs?) con eselect e poi dare semplicemente emerge opzioni pacchetti, oppure devo scrivere diversamente?

Grazie!

----------

## !equilibrium

 *Tigerwalk wrote:*   

> devo attivare il modulo tmpfs (anche oldtmpfs?) con eselect e poi dare semplicemente emerge opzioni pacchetti, oppure devo scrivere diversamente?
> 
> Grazie!

 

sì, devi abilitare i moduli che ti interessano tramite eselect.

poi procedi ad installare i pacchetti di portage come fai normalmente.

p.s.: evita oldtmpfs, c'è solo per retrocompatibilità, ma è fortemente dannoso per la tua salute e quella del tuo pc.

----------

## Tigerwalk

 *!equilibrium wrote:*   

> 
> 
> sì, devi abilitare i moduli che ti interessano tramite eselect.
> 
> poi procedi ad installare i pacchetti di portage come fai normalmente.
> ...

 

Grazie mille!

----------

## sanzo77

Ieri mi sono accorto che c'era un'aggiornamento del bashrc-ng (eh si e' un po' che non uso il sistema ^^), quindi ho aggiornato.

Fatemi capire bene se ho capito bene (hehehe) d'ora in poi non posso + dimensionare lo slot di memoria da assegnare a quella compilazione giusto? Lo fa in automatico lui? E come dice Equilibrium non devo mettere nessuna variabile PORTAGE_MEMSIZE ne nel make.conf ne nel /etc/portage/bashrc-ng/bashrc-ng.conf.

Nel caso ( a questo punto pero' non capisco quando si dovrebbe verificare ) in cui avessi bisogno di compilare su disco devo semplicemente disabilitare il modulo tmpfs tramite eselect e poi riabilitarlo?

Grazie per il supporto  :Razz: 

----------

## sanzo77

No, c'è qualcosa che non va, la compilazione di openoffice è qualcosa di madornale, con il fatto che non posso limitare lo slot assegnato alla compilazione quello si prende tutto compreso lo swap, risultato è che compilando openoffice il sistema è praticamente in panne.

----------

## Kernel78

 *sanzo77 wrote:*   

> No, c'è qualcosa che non va, la compilazione di openoffice è qualcosa di madornale, con il fatto che non posso limitare lo slot assegnato alla compilazione quello si prende tutto compreso lo swap, risultato è che compilando openoffice il sistema è praticamente in panne.

 

Se non ricordo male la compilazione di OpenOffice.org richiede circa 4 gb di spazio ... e se tu impostassi una limitazione otterresti un errore di disk full e non riusciresti a terminare la compilazione cmq.

Soluzioni possibili :

- aumenti lo swap in modo che ram + swap > 4gb

- installi app-office/openoffice-bin e risparmi tempo e spazio

----------

## sanzo77

la seconda che hai detto ^^

Pero' non capisco, prima con la vecchia versione di bashrc oo me lo compilava allocando 1Gb, la cosa importante era che lo facessi da solo, perche' a volte mi rimaneva appesa della memoria e quindi andava come dicevi tu in disk full.

Adesso questo non e' + possibile, cmq usero' il bin come del resto faccio con firefox visti i tempi altrimenti biblici di compilazione.

Grazie cmq dell'aiuto  :Razz: 

----------

## Kernel78

 *sanzo77 wrote:*   

> prima con la vecchia versione di bashrc oo me lo compilava allocando 1Gb

 

bashrc non varia lo spazio richiesto per la compilazione di un pacchetto, se una cerca versione di un pacchetto compilato con determinate USE e CFLAGS richiede un determinato spazio continuerà a richiedere quello ad ogni ricompilazione a prescindere che avvenga in memoria o su disco.

----------

## Onip

```
# echo 'categoria/pacchetto' >> /etc/portage/package.nomem
```

ed hai disabilitato per il pacchetto (o i pacchetti) che vuoi la compilazione in ram.

----------

## skypjack

Scusate, ma compilando wxGTK (usando ovviamente la compilazione in RAM) mi sono accorto che ho occupata la RAM per il 50% e lo spazio di swap per il 100%, con il sistema che si impicca nel paging senza via d'uscita costringendo al riavvio coatto. Il file /etc/portage/bashrc-ng.conf è bianco, ovvero usa le impostazioni di default (per cui, PRESERVE_MEMSIZE=64).

La domanda non è come escludere pacchetti dalla compilazione in RAM (scritto nel post subito sopra), ma piuttosto perché non è superato il 50% nell'uso della RAM e un consiglio sul valore per PRESERVE_MEMSIZE visto che 64 mi pare evidente non sia sufficiente (almeno nel mio caso).

Resto in attesa di consigli. Se mi sono dimenticato qualcosa, chiedete pure.

Grazie in anticipo.

----------

## !equilibrium

 *skypjack wrote:*   

> Resto in attesa di consigli. Se mi sono dimenticato qualcosa, chiedete pure.

 

uhmmm interessante segnalazione, puoi dirmi esattamente che kernel stai usando e la versione?

mi incolli anche l'output di /etc/sysctl.conf?

----------

## skypjack

 *!equilibrium wrote:*   

>  *skypjack wrote:*   Resto in attesa di consigli. Se mi sono dimenticato qualcosa, chiedete pure. 
> 
> uhmmm interessante segnalazione, puoi dirmi esattamente che kernel stai usando e la versione?
> 
> mi incolli anche l'output di /etc/sysctl.conf?

 

Ciao.

Senti, ora in realtà non sono sul mio pc e non posso darti le info che mi hai chiesto, però posso dirti altro che ho raccolto dopo (rimandando quanto chiesto appena metto le mani sulla mia macchina).

In pratica, la prima volta mi ha mostrato il comportamento di cui sopra.

La seconda, invece (mai domo ho riprovato) e ho notato che la ram era usata in modo più consistente fino al momento in cui non veniva richiesto lo spazio di swap, dopo di che l'uso della ram calava intorno al 60%-70% (con picchi inferiori sul 50%) mentre lo spazio di swap veniva sfruttato in modo più pesante. E qui mi interrompo. Questo comportamento è andato bene per compilare gcc-3 e gcc-4, entrambi sono arrivati a termine occupando circa il 70% di spazio di swap e un 50% di memoria una volta che hanno iniziato ad attingere allo spazio di swap. Tornando invece a wxGTK, lo spazio di swap viene saturato e la compilazione si blocca (piantando il sistema intero) in uno swapping fraudolento. La memoria minima in realtà non è (o almeno non sembra essere, è difficile controllare nel momento del collasso) mantenuta e il sistema lo posso riavviare solo in maniera forzata.

Poco chiaro, forse, ma ho cercato di darti un'idea più completa possibile.

Fammi pure tutte le domande che vuoi, appena sono sul mio sistema ti fornisco tutti i dati (se posso).

Rimango in attesa.

----------

## !equilibrium

 *skypjack wrote:*   

> Rimango in attesa.

 

mi servirebbe sapere anche la dimensione della tua RAM e dello SWAP, un cat /proc/meminfo è sufficiente.

----------

## skypjack

Questi me li ricordo, anche senza il mio pc: 1Gb di ram, 512Mb di spazio swap.

[EDIT]: per quanto riguarda il resto, abbiamo:

gentoo sources 2.6.22-r7

niente di rilevante in /etc/sysctl.conf

Altro?

----------

## !equilibrium

 *skypjack wrote:*   

> [*]niente di rilevante in /etc/sysctl.conf
> 
> Altro?

 

la versione esatta di wxGTK che stai installando

p.s.: riportami ugualmente il contenuto di /etc/sysctl, non si sà mai; e quando avrai di nuovo sotto mano il pc, mi serve l'output completo di /proc/meminfo per delle verifiche.

----------

## skypjack

 *!equilibrium wrote:*   

> 
> 
> la versione esatta di wxGTK che stai installando
> 
> p.s.: riportami ugualmente il contenuto di /etc/sysctl, non si sà mai; e quando avrai di nuovo sotto mano il pc, mi serve l'output completo di /proc/meminfo per delle verifiche.
> ...

 

x11-libs/wxGTK-2.6.4.0-r1

/proc/meminfo

```

MemTotal:      1026780 kB

MemFree:        323232 kB

Buffers:         45500 kB

Cached:         306300 kB

SwapCached:          0 kB

Active:         355840 kB

Inactive:       206496 kB

HighTotal:      121676 kB

HighFree:          232 kB

LowTotal:       905104 kB

LowFree:        323000 kB

SwapTotal:      498004 kB

SwapFree:       498004 kB

Dirty:            2484 kB

Writeback:           0 kB

AnonPages:      210636 kB

Mapped:          82428 kB

Slab:            19832 kB

SReclaimable:    11652 kB

SUnreclaim:       8180 kB

PageTables:       3348 kB

NFS_Unstable:        0 kB

Bounce:              0 kB

CommitLimit:   1011392 kB

Committed_AS:   454800 kB

VmallocTotal:   114680 kB

VmallocUsed:     10660 kB

VmallocChunk:   103540 kB

```

/etc/sysctl.conf

```

net.ipv4.conf.default.rp_filter = 1

net.ipv4.conf.all.rp_filter = 1

```

----------

## !equilibrium

 *skypjack wrote:*   

> [*]x11-libs/wxGTK-2.6.4.0-r1
> 
> ```
> 
> MemTotal:      1026780 kB
> ...

 

ho fatto un po di test, innanzitutto per la versione 2.6.4* di wxGTK sono necessati come minimo ~2.5Gb di spazio, quindi il tuo 1.4Gb di RAM+SWAP non è sufficiente; non sono riuscito a riprodurre il tuo problema in nessun modo (anche forzando valori di RAM e SWAP identici ai tuoi), per cui ipotizzo che il freeze sia dovuto al fatto che mentre compilavi hai impegnato il PC con altri software, motivo per cui sto migliorando il tool al fine di evitare questo tipo di situazioni.

----------

## skypjack

 *!equilibrium wrote:*   

> 
> 
> ho fatto un po di test, innanzitutto per la versione 2.6.4* di wxGTK sono necessati come minimo ~2.5Gb di spazio, quindi il tuo 1.4Gb di RAM+SWAP non è sufficiente; non sono riuscito a riprodurre il tuo problema in nessun modo (anche forzando valori di RAM e SWAP identici ai tuoi), per cui ipotizzo che il freeze sia dovuto al fatto che mentre compilavi hai impegnato il PC con altri software, motivo per cui sto migliorando il tool al fine di evitare questo tipo di situazioni.
> 
> 

 

Ottimo. Felice di esserti stato di aiuto e se ti servo per altri test o vuoi altri dati chiedi pure.

A dire la verità, ora non ricordo cosa avevo aperto in quel momento, sarò sincero, ma solitamente quando compilo faccio "cose leggere" proprio per non inginocchiare il sistema (o sclerare per la sua poca reattività). Pensavo, ma smentiscimi se hai argomentazioni, a qualche configurazione azzardata nel kernel o particolarmente mal digerita dal programma, se questo può in qualche modo influire. Te lo chiedo perché conosci il tuo software e mi sai dire al volo se la cosa è plausibile.

Non so, se posso darti un consiglio o qualche suggerimento da utente (a cui puoi anche rispondere "non è possibile"), dovrebbe esserci un controllo a priori sulal possibilità o meno di farcela e quindi una decisione se passare in modalità compilazione su disco. Mi dirai, ma come può farlo a priori? Vero, mi rendo conto che la cosa non è possibile ... E accorgersi durante che la memoria non basta, quindi fermarsi e passare su disco?

Boh ... Sono solo idee, come detto, feedback a cui dare il peso che meritano ...

Buon lavoro e complimenti.

----------

## shogun_panda

Ciao ragazzi... (avete visto...ancora non muoio  :Very Happy: )

Volevo solo fare una domanda a Equilibrium...

Come già ti ho chiesto sul sito gechi.it, a che punto sei con lo sviluppo del modulo autopatch? (ne sono dipendente!  :Very Happy: )

Grazie di tutto...ciao ciao!

----------

## djinnZ

@equilibrium: domandina semplice semplice, ma i moduli di bashrcng-1.1.x dove sono?! Non riesco a trovarli da nessuna parte. (anche incompleti, mi accontento)

----------

## !equilibrium

 *djinnZ wrote:*   

> @equilibrium: domandina semplice semplice, ma i moduli di bashrcng-1.1.x dove sono?! Non riesco a trovarli da nessuna parte. (anche incompleti, mi accontento)

 

ciao, per ora  esiste solo app-portage/bashrcng-shmfs (ed è completo e funzionante); per gli altri, segui gli updates che verranno notificati sul forum GeCHI nelle apposite sezioni (quando i vari plugin saranno completi o quanto meno usabili, verranno notificati anche su questo forum).

----------

## Ashfoot

Ho seguito le info sul sito dei gechi...

```

# layman -s gechi

# echo "app-portage/bashrcng" >> /etc/portage/package.keywords

# echo "app-admin/eselect-bashrcng" >> /etc/portage/package.keywords

# echo "virtual/bashrcng" >> /etc/portage/package.keywords

# emerge -av virtual/bashrcng:1.1

```

AM riscontro il seguente problema

```

gehenna ~ # eselect bashrcng list-profiles

Available bashrc targets:

  [1]   none (disabled bashrcng) *

  [2]   1.1.3

gehenna ~ # eselect bashrcng set 2

!!! Error: Sorry, /etc/portage/bashrc confuses me

Killed

```

Cosa sbaglio?

----------

## !equilibrium

 *Ashfoot wrote:*   

> Cosa sbaglio?

 

nulla, per favore posta l'output di "ls -la /etc/portage/bashrc".

----------

## Ashfoot

Eccolo

```

gehenna ~ # ls -la /etc/portage/bashrc

-rw-r--r-- 1 root root 3360 24 mar  2007 /etc/portage/bashrc

gehenna ~ #

```

----------

## !equilibrium

 *Ashfoot wrote:*   

> Eccolo

 

non è un file di bashrcng, rimuovilo.

----------

## Ashfoot

Fatto e ora va alla stragrandissima!!!!!

             Paolo

----------

## comio

Una domanda: solo a me non vengono smontate le directory di compilazione? Vedo un "rmdir: /var/tmp/portage/pacchetto: Dispositivo o risorsa occupata" a fine emerge ... ho il sospetto che non mi venga chiamato l'hook giusto. Mi pare che non venga invocata da emerge la fase clean... :S

un po' di dati:

```

[I] app-admin/eselect-bashrcng [1]

     Installed versions:  0.2.0(10:15:17 19/01/2008)

[I] app-portage/bashrcng [1]

     Installed versions:  1.1.3((get_major_version)(10:15:22 19/01/2008)(linguas_it -doc -linguas_en -symlink)

[I] app-portage/bashrcng-core [1]

     Installed versions:  1.1.1(10:15:36 19/01/2008)(linguas_it -doc -elibc_FreeBSD -linguas_en -test)

[I] app-portage/bashrcng-shmfs [1]

     Installed versions:  1.2.4(10:15:51 19/01/2008)(linguas_it -doc -elibc_FreeBSD -linguas_en -test)

[I] virtual/bashrcng [1]

     Installed versions:  1.1(1.1)(10:40:12 19/01/2008)

[I] sys-apps/portage

     Installed versions:  2.1.4(13:25:38 12/01/2008)(-build -doc -epydoc -linguas_pl -selinux)

```

Ricordo che io vivo con il sistema in ~amd64.

ciao

luigi

----------

## !equilibrium

 *comio wrote:*   

> Ricordo che io vivo con il sistema in ~amd64.

 

non dipende da bashrcng, ma dal pacchetto 'portage' il quale non esporta (almeno per il momento) l'ebuild phase 'clean'.

purtroppo non posso farci nulla, l'unica è andare a scomodare il devel @zmedico e chiedergli di sistemare la cosa.

----------

## comio

 *!equilibrium wrote:*   

>  *comio wrote:*   Ricordo che io vivo con il sistema in ~amd64. 
> 
> non dipende da bashrcng, ma dal pacchetto 'portage' il quale non esporta (almeno per il momento) l'ebuild phase 'clean'.
> 
> purtroppo non posso farci nulla, l'unica è andare a scomodare il devel @zmedico e chiedergli di sistemare la cosa.

 

Sì ho notato anche io (ho messo delle print dentro bashrc). Secondo te come è meglio muoverci? segnaliamo il bug? 

luigi

----------

## comio

qualcuno mi indica l'ultima versione di portage che funziona? facendo un diff magari becco il problema.

Con il mio fantastico inglese ho aperto un bug: ebuild [pack] clean doesn't perform the custom bashrc call.

ciao

luigi

----------

## Onip

```

[I] sys-apps/portage

     Available versions:  *2.0.51.22-r3 *2.1.1-r2 *2.1.2.12 *2.1.3.19 ~*2.1.4

     Installed versions:  2.1.3.19(17:52:14 13/11/2007)(elibc_glibc userland_GNU -build -doc -elibc_FreeBSD -elibc_uclibc -epydoc -linguas_pl -selinux)

     Homepage:            http://www.gentoo.org/proj/en/portage/index.xml

     Description:         Portage is the package management and distribution system for Gentoo

```

l'ultima stabile su x86, da me funziona. oltre non so.

----------

## comio

 *Onip wrote:*   

> 
> 
> ```
> 
> [I] sys-apps/portage
> ...

 

Analizzando il codice di ebuild.sh dalla riga 1605 (2.1.4) sembra che di proposito non venga caricato il bashrc quando la fase è "clean"... why? quale riflessione sui massimi sistemi a portato a questa scelta?

Comunque modificherei l'ebuild di bashrcng-shmfs per esplicitare l'incompatibilità con portage 2.1.4.

EDIT.: sul bug ha risposto uno sviluppatore con la patch (onestamente non l'ho postata io perché pensavo fosse una decisione prese e non un bug). suppongo che al prossimo giro dovrebbe tornare tutto ok.

luigi

----------

## lucapost

ho appena scaricato l'ebuild  da http://portage-bashrc.cvs.sourceforge.net/*checkout*/portage-bashrc/portage-bashrc-ng/portage-bashrc-ng-0.13_beta.ebuild.

Solo che non funge troppo corettamente, infatti mi devo smontare la /var/tmp/* da solo.

Questo è quello che ottengo durante la compilazione:

```

....

....

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

umount: /var/tmp/portage/app-shells/dash-0.5.4.6-r1: device is busy

umount: /var/tmp/portage/app-shells/dash-0.5.4.6-r1: device is busy                                                                                      [ ok ]

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

umount: /var/tmp/portage/app-shells/dash-0.5.4.6-r1: device is busy

umount: /var/tmp/portage/app-shells/dash-0.5.4.6-r1: device is busy                                                                                      [ ok ]

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

umount: /var/tmp/portage/app-shells/dash-0.5.4.6-r1: device is busy

umount: /var/tmp/portage/app-shells/dash-0.5.4.6-r1: device is busy                                                                                      [ ok ]

 * Cannot umount tmpfs, erasing contents. ...

 * At this point I should remove '/var/tmp/portage/app-shells/dash-0.5.4.6-r1' but I won't :)                                                            [ ok ]

>>> app-shells/dash-0.5.4.6-r1 merged.

rmdir: failed to remove `/var/tmp/portage/app-shells/dash-0.5.4.6-r1': Device or resource busy

>>> Recording app-shells/dash in "world" favorites file...

>>> No packages selected for removal by clean

>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * Messages for package app-shells/dash-0.5.4.6-r1:

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

 * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.

 * At this point I should remove '/var/tmp/portage/app-shells/dash-0.5.4.6-r1' but I won't :)

 * GNU info directory index is up-to-date.
```

ps: sarebbe bello avere la guida aggiornata anche qui sul forum italiano!

----------

## !equilibrium

 *lucapost wrote:*   

> ho appena scaricato l'ebuild  da http://portage-bashrc.cvs.sourceforge.net/*checkout*/portage-bashrc/portage-bashrc-ng/portage-bashrc-ng-0.13_beta.ebuild.

 

il primo post di questo thread riporta: 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.

 *lucapost wrote:*   

> Solo che non funge troppo corettamente

 

Molto probabilmente non funziona perchè l'ebuild di quel repository è sbagliato. usa il GeCHI Overlay che contiene ebuild/versioni aggiornate.

p.s.: il tool portage-bashrc-ng è deprecato da 2 anni oramai, se puoi utilizza il pacchetto app-portage/bashrcng e i relativi plugin (è sempre sul GeCHI Overlay), i quali sostituiscono in toto il vecchio portage-bashrc-ng:

http://www.gechi.it/node/160

http://www.gechi.it/node/161

 *lucapost wrote:*   

> Questo è quello che ottengo durante la compilazione:
> 
>  * Found temporary portage compile dir (/var/tmp/portage/app-shells/dash-0.5.4.6-r1), umounting.
> 
> umount: /var/tmp/portage/app-shells/dash-0.5.4.6-r1: device is busy
> ...

 

sei sicuro al 100% che il percorso /var/tmp/portage/*/* non sia locked da qualche console ancora attiva che punta a quel path?

 *lucapost wrote:*   

> ps: sarebbe bello avere la guida aggiornata anche qui sul forum italiano!

 

guida di cosa?

----------

## mrfree

Non trovo il plugin per-package nel gechi overlay...   :Confused: 

----------

## cloc3

passando (finalmente) al nuovo bashrcng, mi ha "infastidito" un tantino la nomenclatura imposta alle patch:

 *http://www.gechi.it/node/163 wrote:*   

> 
> 
> Le patch, per poter essere rilevate correttamente dal plugin, DEVONO SEGUIRE OBBLIGATORIAMENTE lo standard usato da portage per la nomenclatura delle stesse:
> 
> ¹ $PN_*.{patch,diff}
> ...

 

in questo modo la denominazione del vecchio bashrc-ng non funziona più:

 *Quote:*   

> 
> 
> <nome_pacchetto>trattino<versione>-<commento arbitrario>.patch
> 
> 

 

adesso, al posto del trattino è obbligatorio l'underscore.

perché? in che senso dici che ciò corrisponde allo standard di portage? a me pare che le patch attuali usino proprio il trattino normale.

----------

## !equilibrium

 *cloc3 wrote:*   

> adesso, al posto del trattino è obbligatorio l'underscore.
> 
> perché? in che senso dici che ciò corrisponde allo standard di portage? a me pare che le patch attuali usino proprio il trattino normale.

 

immagino ti stia riferendo a me (anche se non è ben chiaro dal tuo post) e per quanto riguarda le "patch" e le "bulk patch¹", ho solo fatto riferimento a quello che è stato stabilito dai devel gentoo per tale differenziazione; non mi sono inventato nulla se è questo che stai insinuando e c'è un buon motivo perchè ho usato tale standard.

¹ - le patch create per bashrcng-patching vanno considerate come "bulk patch" perchè non sono patch standard per il tree di portage e nella prossima versione del tool, lo standard sulla nomenclatura "bulk" verrà usato con maggiore accuratezza.

----------

## !equilibrium

 *mrfree wrote:*   

> Non trovo il plugin per-package nel gechi overlay...  

 

non serve più. usa direttamente gli "environment profile" di portage.

p.s.: ho in previsione lo sviluppo di uno strumento eselect per la gestione automatizzata di tali profili, ma non ho ancora scritto nemmeno una riga di codice a riguardo.

----------

