Page 4 of 13
Posted: Sat Jun 24, 2006 8:13 pm
by 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ò
.
Ciao
Posted: Sat Jun 24, 2006 9:02 pm
by 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ò
.
Ciao
non mi sembra tropo complesso:
Code: Select all
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
Posted: Sat Jun 24, 2006 10:00 pm
by 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
Posted: Sun Jun 25, 2006 12:41 pm
by .: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
Posted: Sun Jun 25, 2006 2:14 pm
by 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
Posted: Sun Jun 25, 2006 8:34 pm
by 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
) ho conficurato tutto con eselect e va bene
P.S: L'ebuild non dovrebbe toccare minimamente il file bashrc-ng.conf, a meno che non sia stata installata una versoine vecchia... boh
Posted: Sun Jun 25, 2006 9:19 pm
by fabius
C'è qualche motivo particolare per richiedere tra le dipendenze
Code: Select all
>=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
Code: Select all
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.
Posted: Mon Jun 26, 2006 4:53 pm
by 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
Posted: Mon Jun 26, 2006 10:34 pm
by 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
Posted: Fri Jun 30, 2006 2:32 pm
by !equilibrium
fabius wrote:C'è qualche motivo particolare per richiedere tra le dipendenze
Code: Select all
>=sys-apps/coreutils-5.96
>=sys-devel/patch-2.5.9
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.ph ... tid=852160
spero che la segnalazione venga accolta con buon senso e non come una guerra personale
Posted: Sat Jul 01, 2006 9:21 am
by 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...
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
Posted: Sat Jul 01, 2006 10:00 am
by 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 [post=3413711]sul forum internazionale[/post].
Ciao
P.S. Sto scrivendo da una tastiera qwertz con layout tedesco, penso che tra un po´ comincio a urlare...
Posted: Sat Jul 01, 2006 10:38 am
by fabius
Domanda scema: ora enotice non è superato con il supporto ELOG di portage?
Posted: Sat Jul 01, 2006 11:03 am
by 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
Posted: Tue Jul 11, 2006 2:29 pm
by 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!
Posted: Tue Jul 11, 2006 2:43 pm
by 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
Posted: Tue Jul 11, 2006 2:45 pm
by 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...
Grazie ancora
Ciao
effettivamente questo effetto mi capitava... ma non ho pensato al bashrc...
ciao
Posted: Tue Jul 11, 2006 2:48 pm
by !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:
http://bugs.gentoo.org/show_bug.cgi?id=138589
il problema si è risolto installando la versione unstable di quel pacchetto e delle JDK.
Posted: Tue Jul 11, 2006 2:52 pm
by 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
Posted: Tue Jul 11, 2006 3:02 pm
by !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.
Posted: Tue Jul 11, 2006 3:26 pm
by 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..
fix
Posted: Wed Jul 12, 2006 7:07 am
by 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:
Code: Select all
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
Re: fix
Posted: Wed Jul 12, 2006 7:40 am
by 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
Re: fix
Posted: Wed Jul 12, 2006 7:50 am
by 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
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
Re: fix
Posted: Sun Jul 16, 2006 9:29 pm
by 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