Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
GeCHI Weekly Report #1.4
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Forum italiano (Italian) Forum di discussione italiano
View previous topic :: View next topic  
Author Message
oRDeX
Veteran
Veteran


Joined: 19 Oct 2003
Posts: 1325
Location: Italy

PostPosted: Sat Oct 17, 2009 2:18 pm    Post subject: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORTANTE Reply with quote

Quarto report settimanale dei GeCHI.
Come al solito, rinnovo l'invito a commentare il thread e ricordo che in fondo sono presenti le referenze per seguire i report tramite RSS.

==

GeCHI Weekly Report #1.4

Benvenuti al quarto GeCHI Weekly Report, il quale fornisce sommari e notizie importanti relative allo sviluppo della distribuzione Gentoo riguardanti il seguente periodo: 09.10.2009 - 15.10.2009.

[1] Hardened sys-devel/gcc-4.3.4 (stabilizzazione) (13.10)
Di recente, per i profili hardened, è stata stabilizzata la versione 4.3.4 di sys-devel/gcc, la quale differisce rispetto alla precedente versione stabile 3.4.6 del compilatore per le seguenti feature:

tutte le altre ottimizzazioni tipiche del compilatore hardware restano invariate. Per l'upgrade si raccomanda di seguire i consigli riportati al paragrafo [2] Istruzioni per un aggiornamento generale della guida ufficiale Gentoo: Guida all'aggiornamento di GCC per Gentoo

[2] Monthly Gentoo Council (12.10)
Il 12 ottobre si è svolto l'incontro mensile del Consiglio Gentoo in cui si è discusso se i vari package manager di Portage devono o meno preservare i timestamps dei files quando emerge installa i file; la decisione finale è stata quella di preservare i timestamps per garantire una migliore QA ed evitare il verificarsi di bug e regressioni quali:

Portage preserva i timestamps dalla versione 2.1.2.10, così come pkgcore, mentre Paludis non è PMS compliant ed è quindi soggetto a tutte le problematiche legate alla modifica degli mtimes. Per maggiore informazioni su tali problemi, si consiglia la lettura di questa discussione.

Il resto degli argomenti dell'agenda previsto per questo meeting non sono stati discussi perchè non ci sono stati cambiamenti di rilievo rispetto all'incontro dello scorso mese.

[3] Nuove USE globali (11.10)
Un nuovo RFC è stato presentato riguardante l'introduzione di due nuove USE globali:

  • static-libs - Build static libraries;
  • dbi - Enable dev-db/libdbi (database-independent abstraction layer) support;

Va doverosamente segnalato che l'introduzione della USE globale static-libs sarà l'inizio di una nuova era per la distribuzione Gentoo, in quanto apporterà un netto miglioramento della stabilità e affidabilità dell'intera distribuzione a causa della rimozione dei file *.a (static library) e *.la (libtool archive) che generalmente vengono compilati e installati di default dai pacchetti di Portage, ma che sono praticamente inutili per l'utilizzo desktop/server (fatte le dovute eccezioni che si contano sulle dita di una mano). In modo particolare i file *.la, oltre ad essere inutili, sono anche pericolosi, perchè sono spesso la fonte di random segmentation fault e di comportamenti anomali delle applicazioni (spesso di difficile individuazione e correzione), quindi la loro totale rimozione non può che migliorare la qualità finale delle librerie a tutto vantaggio dell'utente finale che si ritroverà una Gentoo box meno soggetta a "problematiche inesplicabili".

Ci sono anche altri benefici indiretti dovuti alla rimozione dei file *.a/*.la, quali:

    1. tempi di compilazione e installazione ridotti (vedere anche punto 3) - i file *.a, che sono copie statiche dei corrispettivi file *.so, non verrebbero compilati e quindi tanto meno installati, riducendo i tempi di esecuzione delle varie ebuild phase;
    2. minore spreco di spazio - non installando i file *.a/*.la si spreca meno spazio sull'hd e in particolar modo, evitando i file *.la che sono generalmente più piccoli di 1KiB, si evita di sprecare spazio a causa di file eccessivamente piccoli rispetto al block size del filesystem in uso (generalmente 4KiB);
    3. riduzione dell'effetto 'LDPATH Pollution' - molti, se non quasi tutti i file *.a/*.la vengono installati in /usr/lib e siccome non vengono usati, hanno il pessimo effetto di rallentare inultimente il loader e linker di sistema in quanto entrambi devono rifare la scansione di /usr/lib ogni qual volta non trovano una libreria nei path o nella cache di sistema, quindi meno spazzatura c'è in /usr/lib minore saranno i tempi di caricamento e linking (ergo, di compilazione) delle librerie, a tutto vantaggio della reattività del sistema e dell'utente finale;


Affinchè tutti gli ebuild presenti in Portage che installano i file *.a/*.la vengano convertiti all'uso della nuova USE static-libs, sarà necessario attendere un po di tempo, vista l'enorme mole di ebuild da aggiornare e considerando che tutto il processo di conversione è iniziato da poco. Nonostante ciò, i solerti sviluppatori Gentoo, già dallo scorso aprile, hanno reso disponibile in Portage l'utility: dev-util/lafilefixer, tramite la quale è possibile individuare i file *.la con riferimenti errati e correggerli (si consiglia di usarlo regolarmente, soprattutto dopo ogni compilazione).
E' superfluo dire che Gentoo sarà la prima distribuzione Linux in assoluto ad operare la sopra citata operazione, mentre tutte le altre distribuzioni al momento preferiscono 'distribuire' sia le librerie statiche che i lafile, con tutti gli svantaggi del caso.
Per chi fosse interessato ad approfondire ulteriormente l'argomento sulle librerie statiche e i lafiles, si consiglia la lettura dell'esauriente serie di articoli scritti dallo sviluppatore Gentoo Diego 'flameeyes' Pettenò reperibili al seguente link.

[last rites]
Il Gentoo Tree Cleaning Team segnala che i seguenti pacchetti verranno rimossi dal tree di portage entro 30 giorni:
# Markus Meier gentoo.org> (11 Oct 2009)
# mask media-gfx/autopano-sift for removal in 30 days
# use media-gfx/autopano-sift-C instead
media-gfx/autopano-sift

# Jonathan Callen gentoo.org> (11 Oct 2009)
# Old KDE 3.5.9 monolithic ebuilds. Replaced by kde*-meta.
# Masked for removal in 30 days
kde-base/kdeaccessibility
kde-base/kdeaddons
kde-base/kdeadmin
kde-base/kdeartwork
kde-base/kdebase

kde-base/kdeedu
kde-base/kdegames
kde-base/kdegraphics
kde-base/kde
kde-base/kdemultimedia
kde-base/kdenetwork
kde-base/kdepim
kde-base/kdesdk
kde-base/kdetoys

kde-base/kdeutils
kde-base/kdewebdev
# Ulrich Mueller gentoo.org> (11 Oct 2009)
# Blocked by its own dependency, therefore no longer installable.
# Use the news module of app-admin/eselect-1.2* as replacement.
# Masked for removal in 30 days, bug 288560.
app-admin/eselect-news
# Samuli Suominen gentoo.org> (15 Oct 2009)

# ksynaptics is replaced by x11-misc/touchfreeze
# gsynaptics is replaced by gnome-extra/gpointing-device-settings
# libsynaptics is orphaned library
# bug 289170
gnome-extra/gsynaptics
x11-libs/libsynaptics
kde-misc/ksynaptics
# Michael Sterrett gentoo.org> (14 Oct 2009)

# Requires aRTs and last released in 2007
games-engines/kwest
chi fa uso di uno o più dei pacchetti sopra citati è fortemente incoraggiato a trovare alternative oppure a contribuire al loro mantenimento.
----
Puoi seguire i GeCHI Weekly Report tramite i seguenti canali:
- gechi.it RSS Feed;
- Twitter: GeCHI Group | GeCHI RSS Feeds;
- Identi.ca: GeCHI Group | GeCHI RSS Feeds;
- Facebook;
Back to top
View user's profile Send private message
cloc3
Advocate
Advocate


Joined: 13 Jan 2004
Posts: 4787
Location: http://www.gentoo-users.org/user/cloc3/

PostPosted: Sun Oct 18, 2009 7:07 pm    Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT Reply with quote

oRDeX wrote:

Va doverosamente segnalato che l'introduzione della USE globale static-libs sarà l'inizio di una nuova era per la distribuzione Gentoo

proprio l'altro ieri mi ero imbattuto quasi per caso in questo warning:
emerge wrote:

* This version of libogg has stopped installing .la files. This may
* cause compilation failures in other packages. To fix this problem,
* install dev-util/lafilefixer and run:
* lafilefixer --justfixit

quando ho eseguito il fix, ho osservato un numero incredibile di correzioni.
volevo aprire un thread, ma è un periodo che mi cimento solo in interventi di qualità scadente :roll: .

certo che, mentre gentoo si dota di strumenti sempre più sofisticati ed efficienti, per l'utente diventa complicato tenere d'occhio ogni novità.
non capisco però perché consigliate di usare il comando ad ogni compilazione e non è sufficiente applicarlo una tantum per stabilizzare il sistema definitivamente.
_________________
vu vu vu
gentù
mi piaci tu
Back to top
View user's profile Send private message
Scen
Retired Dev
Retired Dev


Joined: 29 Jul 2003
Posts: 2470
Location: Padova, Italy

PostPosted: Mon Oct 19, 2009 7:11 am    Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT Reply with quote

oRDeX wrote:
Paludis non è PMS compliant

D'oh! 8O Questo non l'avrei mai immaginato, ero ancora rimasto che Paludis fosse sempre davanti a Portage su tutto :!:

oRDeX wrote:

Va doverosamente segnalato che l'introduzione della USE globale [b]static-libs sarà l'inizio di una nuova era per la distribuzione Gentoo, in quanto apporterà un netto miglioramento della stabilità e affidabilità dell'intera distribuzione a causa della rimozione dei file *.a (static library) e *.la (libtool archive) che generalmente vengono compilati e installati di default dai pacchetti di Portage,
[...]

Ohhhh, questa è una bella novità, speriamo che le migliore elencate avvengano concretamente 8)
_________________
I was born in a deep forest/I wish I could live here all my life/I am made from stones and roots/My home, these woods and roads
All my life I loved this sound/Of the woods all around/Eagles flies where the winds blows free
Journey is my destiny
Back to top
View user's profile Send private message
!equilibrium
Bodhisattva
Bodhisattva


Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC

PostPosted: Mon Oct 19, 2009 11:59 am    Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT Reply with quote

cloc3 wrote:
quando ho eseguito il fix, ho osservato un numero incredibile di correzioni.
volevo aprire un thread, ma è un periodo che mi cimento solo in interventi di qualità scadente :roll: .


eh sì, il numero di lafiles errati è elevato (colpa di upstream, non di gentoo!), purtroppo chi scrive un software non sempre sa a cosa servono e quando usarli, quindi si limitano a copiare cosa fanno gli altri con i risultati (e relativi problemi) che vedi.

cloc3 wrote:
certo che, mentre gentoo si dota di strumenti sempre più sofisticati ed efficienti, per l'utente diventa complicato tenere d'occhio ogni novità.


è il motivo per cui ho iniziato a scrivere i GWR (a cui seguiranno a ruota altri servizi di informazione) perchè il gap tra l'utente medio e i devel è oramai enorme e negli ultimi due anni ci sono stati troppi allarmismi e FUD infondati del tipo "gentoo è morta" che vorrei stroncare sul nascere nel futuro prossimo.

cloc3 wrote:
non capisco però perché consigliate di usare il comando ad ogni compilazione e non è sufficiente applicarlo una tantum per stabilizzare il sistema definitivamente.


ecco bravo, ora che mi ci hai fatto riflettere, forse è stata un po esagerata la mia affermazione, ma i problemi dei lafiles dipendono molto dal tipo di installazione e dalla frequenza degli aggiornamenti fatti; io in genere ho un alto numero di pacchetti che giornalmente ricompilo e/o installo per svariati motivi, quindi mi ritrovo sempre con tonnellate di lafiles da correggere, ma la situazione non cambia anche se rapportata a frequenze di update inferiori: avrai pochi aggiornamenti e pochi lafiles da correggere, ma ce li avrai sempre.
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe

all my contents are released under the Creative Commons Licence by-nc-nd 2.5
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Mon Oct 19, 2009 12:59 pm    Post subject: Reply with quote

domande in breve:
visto che sono un tantino "distratto" ultimamente non è che qualcuno potrebbe riassumere perchè ssp è stata disabilitata di default?
dato che la situazione mi consiglia di non aggiornare più la gentoo che ho ma di reinstallarla ex novo val la pena di disabilitare globalmente static-libs?
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:
Back to top
View user's profile Send private message
!equilibrium
Bodhisattva
Bodhisattva


Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC

PostPosted: Mon Oct 19, 2009 1:28 pm    Post subject: Reply with quote

djinnZ wrote:
domande in breve:
visto che sono un tantino "distratto" ultimamente non è che qualcuno potrebbe riassumere perchè ssp è stata disabilitata di default?


certo! è questo lo scopo dei GWR, informare da un lato e dare help/feedback agli utenti dall'altro.

per il tuo quesito va fatta una premessa: attualmente SSP è suddiviso in due branch di sviluppo, uno per gcc3 e uno per gcc4, questo per svariati motivi, un po perchè gcc4 è molto diverso da gcc3 e un po perchè il branch per gcc3 è praticamente morto (non viene più sviluppato). sfortunamente SSP per gcc4 non è ancora completo, non ha le stesse funzionalità di gcc3.

da quello che mi risulta SSP dovrebbe essere completo con la stabilizzazione di gcc4.4
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe

all my contents are released under the Creative Commons Licence by-nc-nd 2.5
Back to top
View user's profile Send private message
!equilibrium
Bodhisattva
Bodhisattva


Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC

PostPosted: Mon Oct 19, 2009 3:16 pm    Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT Reply with quote

Scen wrote:
D'oh! 8O Questo non l'avrei mai immaginato, ero ancora rimasto che Paludis fosse sempre davanti a Portage su tutto :!:


strano ma vero, su questo punto Paludis non preserva i timestamp generando quindi molti problemi con la roba python, lisp, ruby e altro; da quando Ciaranm ha fatto il fork di Gentoo con Exherbo, Paludis è nettamente peggiorato, mentre pkgcore è migliorato parecchio (io continuo a preferire Portage 2.2 che nelle ultime versioni ha parecchie killer-feature)

Scen wrote:
Ohhhh, questa è una bella novità, speriamo che le migliore elencate avvengano concretamente 8)


Diego "flameyes" Pettenò ed io siamo in prima linea e non molliamo il fronte fino a quando l'ultimo lafile non verrà rimosso; ho già sistemato un po di ebuild a riguardo nel mese scorso, ma sono davvero tanti da sistemare e i devel sono pochi, per cui si sta optando più per una soluzione unica e definitiva tramite il filtraggio by eclass e portage stesso, così che si vada a colpire la maggior parte degli ebuild con una modifica sola (o una manciata).
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe

all my contents are released under the Creative Commons Licence by-nc-nd 2.5
Back to top
View user's profile Send private message
Apetrini
Veteran
Veteran


Joined: 09 Feb 2005
Posts: 1158

PostPosted: Mon Oct 19, 2009 3:37 pm    Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT Reply with quote

Scen wrote:
oRDeX wrote:
[b]Paludis non è PMS compliant

D'oh! 8O Questo non l'avrei mai immaginato, ero ancora rimasto che Paludis fosse sempre davanti a Portage su tutto :!:


Premetto che sono di parte e la mia è solamente un idea personale. Volevo dire che Paludis è sempre davanti a Portage :)
Il motivo per cui paludis non ha "implementato" la famosa preservazione di mtime è dovuta al fatto che tale caratteristica non è stata spiegata con la dovuta precisione in PMS. Sembra che questa regola sia stata scritta più guardando a quello che già faceva il portage; non è un problema se non fosse che a volte portage ha dei comportamenti ambigui a tal proposito. Definire, quindi, cose del tipo "quando si copia da D a ROOT bisogna preservare sempre gli mtime, salvo in casi in cui è necessario non farlo" non giova al sistema perché è un comportamento ambiguo e in futuro potrebbero esserci problemi (e poi va contro la filosofia di ciaran che vuole bene i puntini sulle i e non lascia nulla al caso).

Giusto per chiarezza, posto in inglese il commento di ciaran (non me la sento di tradurlo per non scambiare accidentalmente pan per polenta nella traduzione)
Quote:

Looking at implementing this, my current list of questions is:

* Preserve mtimes on what? Definitely just regular files?

* Preserve how? Is second-resolution enough, or are we expected to preserve
nanosecond-resolution on systems that support it? What are the implications on
nanosecond-resolution systems where some files are merged by a rename and some
by a copy?

* Which files is the package manager allowed to modify mtimes for?

So far as I can see the Council didn't attempt to address any of these
questions when mandating the EAPI 3 change. Without answers to these, I don't
see the proposal as being implementable either as a standard or in code.


Tornando all'altro discorso io sarei per tenere un thread sticky dove inserire tutti i link e un thread a settimana.
[/code]
_________________
Linux ape 2.6.31-vanilla. Paludis since 0.28.0.
Back to top
View user's profile Send private message
!equilibrium
Bodhisattva
Bodhisattva


Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC

PostPosted: Mon Oct 19, 2009 4:25 pm    Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT Reply with quote

Apetrini wrote:
Il motivo per cui paludis non ha "implementato" la famosa preservazione di mtime è dovuta al fatto che tale caratteristica non è stata spiegata con la dovuta precisione in PMS. Sembra che questa regola sia stata scritta più guardando a quello che già faceva il portage;


non è così, l'argomento è stato discusso in Gentoo Council per tutti e tre i package manager, guarda caso, pure pkgcore è compliant alla questione degli mtimes perchè è un problema noto dalla notte dei tempi.

Apetrini wrote:
non è un problema se non fosse che a volte portage ha dei comportamenti ambigui a tal proposito.


non è vero, non è portage ad avere comportamenti ambigui, l'installazione dei pacchetti andrebbe a buon fine anche senza fare il preserve degli mtimes, ma senza di essi la cache e il bytecode di certi linguaggi interpretati (in primis python, a seguire ruby) smette di funzionare come dovrebbe, generando malfunzionamenti "ambigui" a tutti i pacchetti che ne fanno uso (quindi portage compreso visto che è scritto in python! ma portage non è la causa del sopracitato problema, ne è la vittima indiretta). la questione è ben spiegata nel link del GWR.

Apetrini wrote:
Definire, quindi, cose del tipo "quando si copia da D a ROOT bisogna preservare sempre gli mtime, salvo in casi in cui è necessario non farlo" non giova al sistema perché è un comportamento ambiguo e in futuro potrebbero esserci problemi (e poi va contro la filosofia di ciaran che vuole bene i puntini sulle i e non lascia nulla al caso).


la "filosofia" di ciaranm non è legge, e le sue affermazioni si basano su trip mentali che nessun altro si pone; il problema degli mtimes coinvolge una fetta del tree di portage troppo vasta (hai idea di quanti pacchetti python,ruby,lisp ne sono coinvolti? e mi fermo solo a python,ruby e lisp, ma la questione mtimes va ben oltre) per poter essere risolta dal punto di vista degli ebuild quindi, in questi casi, è preferibile una soluzione unica a livello di PMS (leggi package manager) per risolvere definitivamente il problema alla radice; se tu e ciaranm siete disposti a smazzarvi l'onere di modificare singolamente qualche migliaia di ebuild per aggiustare gli mtimes file per file siete liberi di farlo :roll: scomettiamo che nessuno lo farà e che nemmeno l'incredibile Ciaranm "troverà" la soluzione definitiva, etica e perfetta al problema senza passare dal PMS? :wink: (è da tre anni che i devel discutono sto problema e sta fantomatica soluzione definitiva, etica e perfetta non l'ha trovata ancora nessuno, se Ciaranm ce l'ha perchè non la condivide?)
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe

all my contents are released under the Creative Commons Licence by-nc-nd 2.5
Back to top
View user's profile Send private message
!equilibrium
Bodhisattva
Bodhisattva


Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC

PostPosted: Mon Oct 19, 2009 6:35 pm    Post subject: Reply with quote

djinnZ wrote:
dato che la situazione mi consiglia di non aggiornare più la gentoo che ho ma di reinstallarla ex novo val la pena di disabilitare globalmente static-libs?


non ho capito questa domanda, perchè vorresti disabilitare globalmente static-libs che è già disabilitata di default? se l'abiliti ti installa i file *.a e i lafiles (motivo per cui è disabilitata di default) e comunque non ho capito l'attinenza con la reinstallazione. più info please.
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe

all my contents are released under the Creative Commons Licence by-nc-nd 2.5
Back to top
View user's profile Send private message
cloc3
Advocate
Advocate


Joined: 13 Jan 2004
Posts: 4787
Location: http://www.gentoo-users.org/user/cloc3/

PostPosted: Mon Oct 19, 2009 7:27 pm    Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT Reply with quote

!equilibrium wrote:
purtroppo chi scrive un software non sempre sa a cosa servono e quando usarli, quindi si limitano a copiare cosa fanno gli altri con i risultati (e relativi problemi) che vedi.

quindi lafilfixer è uno strumento indipendente da revdep-rebuild?
mi sfugge ancora l'esatta relazione tra questi due programmi.
_________________
vu vu vu
gentù
mi piaci tu
Back to top
View user's profile Send private message
djinnZ
Advocate
Advocate


Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.

PostPosted: Mon Oct 19, 2009 7:39 pm    Post subject: Reply with quote

Ho capito al contrario, che static-libs fosse abilitata di default per la transizione.
Reistallo perchè per il nuovo gcc devo comunque ricompilare tutto.

gcc 4.4 quindi non prima di un annetto per avere ssp?

@Apetrini: Tanto per dire la sulla polemica per gli mtimes vorrei far notare che sono un problema del portage tree non di emerge in se stesso, per capirci.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt:wink:
mala tempora currunt...mater stultorum semper pregna est :evil:
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist :wink:
Back to top
View user's profile Send private message
!equilibrium
Bodhisattva
Bodhisattva


Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC

PostPosted: Mon Oct 19, 2009 7:54 pm    Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT Reply with quote

cloc3 wrote:
quindi lafilfixer è uno strumento indipendente da revdep-rebuild?
mi sfugge ancora l'esatta relazione tra questi due programmi.


sì, lafilefixer è un semplice script bash che va a leggersi il contenuto dei file .la (che sono dei semplici file di testo a loro volta) e se al loro interno ci sono delle reference sbagliate (librerie vecchie, librerie inesistenti, altri file .la) vengono corretti per puntare alle reference giuste, tutto qua; pensa un po, per uno stupido file di testo che non viene mai usato, ci si ritrova con vagonate di problemi che teoricamente non dovrebbero nemmeno esistere o presentarsi...

djinnZ wrote:
gcc 4.4 quindi non prima di un annetto per avere ssp?


non ne ho idea sinceramente, ma di sicuro non nel giro di pochi mesi ecco.
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe

all my contents are released under the Creative Commons Licence by-nc-nd 2.5
Back to top
View user's profile Send private message
Apetrini
Veteran
Veteran


Joined: 09 Feb 2005
Posts: 1158

PostPosted: Mon Oct 19, 2009 8:16 pm    Post subject: Reply with quote

@!equilibrium:

Credo di essere stato in parte frainteso. Quando ho detto che il portage ha comportamenti ambigui intendevo un'altra cosa. Sebbene si dica che il portage è PMS compliant e che preserva gli mtimes, qualcuno dice(io oramai non posso parlare perché non uso emerge da piu di un anno e mezzo) che ci sono situazioni in cui ad alcuni file non viene preservato mtimes. Ora, la domanda sorge spontanea, quando questo è permesso e quando no.

Ma lasciamo perdere questo dettaglio degli mtimes e guardiamo la questione in una maniera più generica (che secondo me è anche il nocciolo della questione nonché la mia personale interpretazione del pensiero di ciaranm).

Se si crea uno standard, o meglio, una specifica (in questo caso PMS) bisognerebbe esprimere in maniera molto precisa i modi, i vincoli e quant'altro riguardi la suddetta. Se ciaranm ha delle domande riguardo all'implementazione/procedure di alcune cose è giusto che gli venga data una risposta; chi meglio di coloro che hanno stilato la specifica possono rispondere alle domande? Se poi la specifica non esplica alcune cose(magari anche seghe mentali), gli autori hanno 2 strade: o viene spiegata meglio e viene aggiunta una postilla(passatemi il termine) alla specifica oppure si decide di non aggiungere nulla etichettando la domanda/quesito come "non rilevante".
Ora il problema, secondo me, è che se qualcosa viene definito "non rilevante" deve essere "non rilevante" anche in futuro (per quanto possibile).
La tipica situazione che si vuole evitare è: "abbiamo detto che era irrilevante, ma poi ci siamo accorti che emerge assume un certo comportamento in proposito e in realtà se non si assume lo stesso comportamento di emerge, non funziona".
Io credo che ciaranm voglia solo delle risposte...

In tutta questa faccenda si sta perdendo, secondo me, la finalità principale di PMS, ovvero l'indipendenza totale dal package manager. E' naturale pensare che emerge faccia un po' da traino, ma se alcune scelte rendono "le cose piu facili" andando però contro la finalità principale del PMS, be queste scelte non mi trovano affatto d'accordo.
Per quanto mi riguarda è meglio avere una specifica giusta e un implementazione sbagliata che un implementazione ottima di una specifica barlocca.

P.s. probabilmente ho preso troppo alla lettera l'obiettivo della PMS, ma secondo me è una grande idea e sicuramente richiede dei grossi sforzi.
_________________
Linux ape 2.6.31-vanilla. Paludis since 0.28.0.
Back to top
View user's profile Send private message
cloc3
Advocate
Advocate


Joined: 13 Jan 2004
Posts: 4787
Location: http://www.gentoo-users.org/user/cloc3/

PostPosted: Wed Oct 28, 2009 9:38 am    Post subject: Re: GeCHI Weekly Report #1.4 (novità dal mondo Gentoo)IMPORT Reply with quote

oRDeX wrote:
Nonostante ciò, i solerti sviluppatori Gentoo, già dallo scorso aprile, hanno reso disponibile in Portage l'utility: dev-util/lafilefixer

ho incontrato un fastidiosissimo effetto collaterale associato all'uso di lafilefixer che impone una segnalazione:
i successivi controlli del sistema tramite chiamata a qcheck generano una lista infinita di falsi positivi.
_________________
vu vu vu
gentù
mi piaci tu
Back to top
View user's profile Send private message
riverdragon
Veteran
Veteran


Joined: 14 Sep 2006
Posts: 1269
Location: Verona

PostPosted: Wed Oct 28, 2009 10:14 am    Post subject: Reply with quote

Perché non usi semplicemente lafilefixer --justfixit e lo lasci arrangiarsi?
Back to top
View user's profile Send private message
cloc3
Advocate
Advocate


Joined: 13 Jan 2004
Posts: 4787
Location: http://www.gentoo-users.org/user/cloc3/

PostPosted: Wed Oct 28, 2009 10:42 am    Post subject: Reply with quote

riverdragon wrote:
Perché non usi semplicemente lafilefixer --justfixit e lo lasci arrangiarsi?

è esattamente il comando che genera il problema.

dopo il passaggio di lafilefixer, tutti i file corretti assumono un md5sum diverso da quello originale conservato nel database di sistema, dunque qcheck li considera corrotti.
_________________
vu vu vu
gentù
mi piaci tu
Back to top
View user's profile Send private message
!equilibrium
Bodhisattva
Bodhisattva


Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC

PostPosted: Wed Oct 28, 2009 10:48 am    Post subject: Reply with quote

cloc3 wrote:
dopo il passaggio di lafilefixer, tutti i file corretti assumono un md5sum diverso da quello originale conservato nel database di sistema, dunque qcheck li considera corrotti.


quale preferisci tra i due mali? una gentoo che segfault casualmente o avere il comando qcheck con falsi positivi? :lol:

p.s.: la soluzione definitiva è solo una: rimboccarsi le maniche e modificare gli ebuild affinchè vengano rimossi i lafiles.
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe

all my contents are released under the Creative Commons Licence by-nc-nd 2.5
Back to top
View user's profile Send private message
cloc3
Advocate
Advocate


Joined: 13 Jan 2004
Posts: 4787
Location: http://www.gentoo-users.org/user/cloc3/

PostPosted: Wed Oct 28, 2009 12:40 pm    Post subject: Reply with quote

!equilibrium wrote:

quale preferisci tra i due mali?

capisco bene.
ma questo implica dei problemi di comunicazione.

l'utente non deve considerare lafilefixer come un software di sistema, ma come uno strumento estraneo e provvisorio, integrato solo parzialmente. quanto meno, sarebbe utile inserire qualche avviso opportuno sia nell'ebuild del pacchetto che in ogni luogo ufficiale ove ne venga consigliato l'uso.
_________________
vu vu vu
gentù
mi piaci tu
Back to top
View user's profile Send private message
!equilibrium
Bodhisattva
Bodhisattva


Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC

PostPosted: Wed Oct 28, 2009 1:58 pm    Post subject: Reply with quote

cloc3 wrote:
l'utente non deve considerare lafilefixer come un software di sistema, ma come uno strumento estraneo e provvisorio, integrato solo parzialmente. quanto meno, sarebbe utile inserire qualche avviso opportuno sia nell'ebuild del pacchetto che in ogni luogo ufficiale ove ne venga consigliato l'uso.


allora segnalalo sul bugzilla di gentoo
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe

all my contents are released under the Creative Commons Licence by-nc-nd 2.5
Back to top
View user's profile Send private message
Ic3M4n
Advocate
Advocate


Joined: 02 Nov 2004
Posts: 3489
Location: Bergamo.

PostPosted: Wed Oct 28, 2009 2:46 pm    Post subject: Reply with quote

è stato già segnalato segnato come INVALID.
https://bugs.gentoo.org/show_bug.cgi?id=274585
Back to top
View user's profile Send private message
Scen
Retired Dev
Retired Dev


Joined: 29 Jul 2003
Posts: 2470
Location: Padova, Italy

PostPosted: Wed Oct 28, 2009 3:37 pm    Post subject: Reply with quote

Ic3M4n wrote:
è stato già segnalato segnato come INVALID.
https://bugs.gentoo.org/show_bug.cgi?id=274585

E nel commento #5 viene proposta una soluzione temporanea, direi, semplicemente geniale 8)

Daniel Pielmeier wrote:

If you want correct md5sums you should consider adding something like this to
your /etc/portage/bashrc:

Code:

post_src_install() {
        echo "post_src_install: run lafilefixer ${D}"
        lafilefixer "${D}"
        echo ""
}


This way the libtool archives are fixed after the install phase and before
merging into the system. So the md5sums of the corrected *.la files are stored
and equery does not complain.

_________________
I was born in a deep forest/I wish I could live here all my life/I am made from stones and roots/My home, these woods and roads
All my life I loved this sound/Of the woods all around/Eagles flies where the winds blows free
Journey is my destiny
Back to top
View user's profile Send private message
cloc3
Advocate
Advocate


Joined: 13 Jan 2004
Posts: 4787
Location: http://www.gentoo-users.org/user/cloc3/

PostPosted: Wed Oct 28, 2009 4:25 pm    Post subject: Reply with quote

Scen wrote:
E nel commento #5 viene proposta una soluzione temporanea, direi, semplicemente geniale 8)

infatti. portage possiede in sé gli strumenti per risolvere il caso.
non capisco, a questo punto, perché non si utilizzi direttamente un'istruzione che rimuove i lafile, anziché fissarli.
magari predisponendo una FEATURE apposita da selezionare in make.conf
_________________
vu vu vu
gentù
mi piaci tu
Back to top
View user's profile Send private message
!equilibrium
Bodhisattva
Bodhisattva


Joined: 06 Jun 2004
Posts: 2109
Location: MI/BG/LC

PostPosted: Wed Nov 11, 2009 9:23 am    Post subject: Reply with quote

cloc3 wrote:
non capisco, a questo punto, perché non si utilizzi direttamente un'istruzione che rimuove i lafile, anziché fissarli.magari predisponendo una FEATURE apposita da selezionare in make.conf


in realtà la soluzione non è così semplice; è vero che i lafiles sono il male e vanno rimossi, ma è anche altrosì vero che non si deve fare di tutte le erbe un fascio, ma va valutato singolo caso per singolo caso.

Un esempio ne è app-arch/libarchive-2.7.1 che ho di recente modificato in -r1 (vedere log: /usr/portage/app-arch/libarchive/ChangeLog ) in cui una rimozione indiscriminata dei lafiles avrebbe compromesso il normale funzionamento del pacchetto in determinate circostanze; quindi, se da un lato bisogna rimuovere i lafiles, dall'altro lato bisogna fare attenzione che tali modifiche non diventino una nuova fonte di problemi, ergo, no alle soluzioni di sterminio di massa dei lafiles, sì ad una loro oculata rimozione. (per comprendere meglio il problema: diff -u /usr/portage/app-arch/libarchive/libarchive-2.7.1.ebuild /usr/portage/app-arch/libarchive/libarchive-2.7.1-r1.ebuild)
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe

all my contents are released under the Creative Commons Licence by-nc-nd 2.5
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Forum italiano (Italian) Forum di discussione italiano All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum