# GeCHI Weekly Report #1.12

## !equilibrium

Scusate per il ritardo nella pubblicazione del GWR, ma lo scorso sabato/domenica per me erano festività.

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

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

[1] Monthly Gentoo Council (07.12)

Il 7 dicembre si è svolto l'incontro mensile del Consiglio Gentoo in cui si sono discussi i seguenti argomenti:

Gentoo/Prefix inserito ufficialmente in portage - nel precedente meeting si era deciso di accettare ufficialmente l'introduzione di Gentoo/Prefix in Portage mentre i dettagli tecnici della sua implementazione sarebbero stati sottoposti e discussi al successivo meeting; ciò è stato fatto e ai membri del consiglio è piaciuto il lavoro svolto, quindi è stata data l'approvazione per le modifiche da effettuare a Portage, le quali prenderanno nome come EAPI3 (tutto ciò che in precedenza è stato identificato come EAPI3 verrà rinominato in EAPI4);timestamps preservation per i package manager - siccome gli sviluppatori dei vari package manager ufficiali per Gentoo non sono concordi sulla questione riguardante la conservazione dei timestamps dei file installati (vedere precedente GWR #1.04), i membri del consiglio hanno deciso che i sopra citati sviluppatori devono fornire delle specifiche tecniche dettagliate sul comportamento che i package manager dovrebbero tenere nei confronti degli mtimes, così da avere un quadro più completo della situazione e prendere una decisione definitiva per il problema;[2] Nuove eclass per i pacchetti ruby - Ruby Targets e Fake Gem (06.12)

Nel precedente GWR #1.11 era stata annunciata l'introduzione della nuova eclass ruby-ng e prontamente è stata inserita in Portage come promesso. Oltre alle migliorie già annunciate in precedenza, la nuova eclass introduce una nuova USE_EXPAND chiamata RUBY_TARGETS da settare in make.conf, grazie alla quale sarà possibile avere una migliore gestione delle dipendenze, in modo particolare in quei casi in cui l'utente finale ha la necessità di installare una dipendenza per versioni multiple di Ruby.

Di default RUBY_TARGETS sarà settata con la use ruby18, ma l'utente ha la possibilità di specificare altri targets, quali:

ruby18;ruby19;jruby (JRuby);ree18 (Ruby Enterprise Edition 1.8 );

Al momento la stable release del pacchetto dev-lang/ruby è la versione 1.8, quindi non usate su macchine di produzione altri target oltre a ruby18 (a meno che non stiate facendo testing); di seguito un esempio dell'output in console per i nuovi pacchetti:

 *Quote:*   

> dev-ruby/test-unit-2.0.4 [2.0.3] USE="-test%" RUBY_TARGETS="ruby18%* ruby19%* -jruby%"

 

come si nota facilmente dall'esempio appena riportato, viene aggiunta la nuova USE test e il pacchetto verrà installato sia per la versione 1.8 che la versione 1.9 di Ruby.

Ma le novità non si fermano alla sola eclass ruby-ng, infatti è in corso l'implementazione di una nuova eclass denominata ruby-fakegem che andrà a sostituire l'attuale gems.eclass. La nuova eclass si basa su ruby-ng ed è quindi in grado di gestire in modo del tutto trasparente l'installazione delle gem per target multipli, ma cosa più importante, è in grado di farlo senza usare dev-ruby/rubygems; ciò permetterà di gestire le ruby gems come traduzionali pacchetti di portage e non come pacchetti installati tramite utility esterne a portage (dev-ruby/rubygems) e quindi si avrà la possibilità di applicare loro patch ed eseguire test.

La nuova USE_EXPAND per i target e le fake gem semplificheranno notevolmente l'amministrazione dei pacchetti ruby, eliminando sul nascere ogni possibile errore umano o conflitto di dipendenze, a tutto vantaggio della stabilità del sistema. Attualmente in portage ci sono circa 300 pacchetti che devono essere convertiti alle nuove eclass, quindi non aspettatevi un massiccio cambio di USE nei futuri aggiornamenti, perché tutto il processo di conversione sarà graduale e diluito nel tempo.

[3] nuovi stage per armv4l/armv4tl/armv5tel [EXTRAS]

Lo sviluppatore Gentoo Raúl Porcel ha reso disponibili nuovi stage per l'architettura ARM: armv4l/armv4tl/armv5tel.

[4] nuova veste grafica per il sito packages.gentoo.org [EXTRAS]

Lo sviluppatore Gentoo Steve Dibb, per meglio sopperire alle esigenze degli utenti, sta rifacendo sia la grafica che l'implementazione software del sito packages.gentoo.org. Prima di rilasciare pubblicamente la nuova versione, Steve vorrebbe che il sito venisse testato ampiamente, così da trovare quanti più bug possibili prima che colpiscano l'utente finale, quindi invita tutta la communità internazionale Gentoo a fare testing e fornire feedback; chi volesse provare la beta deve semplicemente contattare Steve Dibb.

[5] GPytage una nuova utility per portage [EXTRAS]

Lo sviluppatore Gentoo Kenneth Prugh ha ripreso lo sviluppo dell'applicazione GPytage, un frontend grafico per la gestione del file di configurazione di Portage; Ken incoraggia la community internazionale Gentoo a fare testing e fornire feedback.

[6] Usare correttamente l'overlay kde-sunset [EXTRAS]

Lo sviluppatore Gentoo Alex Alexander di recente ha pubblicato un articolo sul suo sito che spiega come utilizzare correttamente l'overlay kde-sunset per l'installazione di kde:3.5.

[last rites]

Il Gentoo Tree Cleaning Team segnala che i seguenti pacchetti verranno rimossi dal tree di portage entro 30 giorni:

# Michael Sterrett (mr_bones_ [at] gentoo.org) (07 Dec 2009)

# Last release in 2002; writes to GAMES_DATADIR;

# unmaintained by upstream.

games-fps/nprquake-sdl

# Diego E. Pettenò (flameeyes [at] gentoo.org) (06 Dec 2009)

# libip_vs_user_sync fails to build with current

# linux-headers, bug #247061 open November

# 2008. sys-cluster/saru depends on that.

dev-libs/libip_vs_user_sync

sys-cluster/saru

# Diego E. Pettenò (flameeyes [at] gentoo.org) (06 Dec 2009)

# Coming straight out of the modular Xorg split;

# collides with the (actually used) xbitmaps package (bug

# #295838). ACKed by scarabeus.

x11-apps/xmh

# Diego E. Pettenò (flameeyes [at] gentoo.org) (06 Dec 2009)

# pvm builds but segfaults if compiled with GCC 4. This is

# bug #151316 *Open October 2006!* Over three years later

# the bug is still unsolved; if somebody wants to care for

# this package, please fix it up and feel free to unmask,

# but not before that.

sys-cluster/pvm

sys-cluster/pvm-povray

sys-cluster/pypvm

# Diego E. Pettenò (flameeyes [at] gentoo.org) (05 Dec 2009)

# Upstream closed the early accesss program in favour of

# Sun Studio 12 Update 1. The new package needs its license

# reviewed, once that's done, it'll be added to Portage.

dev-lang/sunstudioexpress

# Diego E. Pettenò (flameeyes [at] gentoo.org) (05 Dec 2009)

# Collides with itself (bug #256230 open January 2009).

app-admin/rackview

# Diego E. Pettenò (flameeyes [at] gentoo.org) (05 Dec 2009)

# Fails to build with recent gcc (4.3) due to _FORTIFY_SOURCE

# (bug #273170 open June 2009); also has other minor problems

# (bug #240788 and bug #244138).

mail-filter/simscan

# Diego E. Pettenò (flameeyes [at] gentoo.org) (05 Dec 2009)

# Fails parallel make and install (bug #295821); unused in

# tree; upstream homepage returns 404.

dev-util/cook

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;YouTube: GeCHI Group;FaceBook: GeCHI Group;Digg: GeCHI Group | GeCHI RSS Feeds

----------

## Apetrini

 *!equilibrium wrote:*   

> 
> 
> [*]Gentoo/Prefix inserito ufficialmente in portage - nel precedente meeting si era deciso di accettare ufficialmente l'introduzione di Gentoo/Prefix in Portage mentre i dettagli tecnici della sua implementazione sarebbero stati sottoposti e discussi al successivo meeting; ciò è stato fatto e ai membri del consiglio è piaciuto il lavoro svolto, quindi è stata data l'approvazione per le modifiche da effettuare a Portage, le quali prenderanno nome come EAPI3 (tutto ciò che in precedenza è stato identificato come EAPI3 verrà rinominato in EAPI4);
> 
> 

 

Ottimo!!!! Gli utilizzatori di portage saranno contenti, perché almeno per come la vedo io è una funzionalità che mancava e che permette molta più flessibilità.

Sono un po' perplesso riguardo alla decisione di rinominare le EAPI3 come EAPI4... Un mio unico dubbio è sul fatto se questa cosa rallenterà ulteriormente lo "sviluppo/inclusione" di nuove funzionalità. Voglio dire... c'è una lista abbastanza corposa delle cose che ci mancano (e non parlo di funzionalità minori, ma funzionalità di uso quotidiano) e si procede con una lentezza esasperante, se ora si imbucano anche strade "infelici" allora si che gli diamo una mazzata a questa povera distro.

 *!equilibrium wrote:*   

> 
> 
> [*]timestamps preservation per i package manager - siccome gli sviluppatori dei vari package manager ufficiali per Gentoo non sono concordi sulla questione riguardante la conservazione dei timestamps dei file installati (vedere precedente GWR #1.04), i membri del consiglio hanno deciso che i sopra citati sviluppatori devono fornire delle specifiche tecniche dettagliate sul comportamento che i package manager dovrebbero tenere nei confronti degli mtimes, così da avere un quadro più completo della situazione e prendere una decisione definitiva per il problema;

 

mmm... da "il package manager ufficiale + 2 non ufficiali" siamo passati ai "3 package manager ufficiali" ??? Sono ancora convinto che avere 3 package manager per gentoo sia una ricchezza e non un difetto. Strade diverse, approcci diversi... con la piccola parentesi che emerge è l'unico che deve "per forza" garantire il supporto a tutto(nel modo canonico) visto che è il pm di default.

Sembra che questa odissea degli mtimes stia giungendo alla fine. La quesione vera non sono comunque gli mtimes, bensì il PMS (come al solito si torna sempre li). Da quello che ho potuto notare (secondo le mie personali impressioni) ci sono 2 "credenze" principali su quello che dovrebbe essere il PMS.

La prima è che il PMS sia una specifica di massima su come dovrebbe funzionare un package manager.

La seconda è che il PMS non ha valore se non specifica tutto, quindi deve essere qualcosa di molto vicino a un RFC.

E' chiaro che in linea teorica avere un RFC sia molto meglio che avere una specifica di massima(che si esprime in maniera ambigua su alcuni punti); ma il rovescio della medaglia è che per stilare un (diciamo) RFC c'è bisogno di uno sforzo immenso e gli sviluppatori gentoo non hanno (si dice) sufficiente forza lavoro per attuare questo compito.

All'inizio l'andazzo generale era di specificare le cose in maniera piu intuitiva che in modo estremamente formale. Ora però, viste anche le molte incomprensioni scaturite, si sta cercando di rendere il PMS sempre piu preciso(quindi sta prendendo un pochino piede l'idea del PMS come un RFC)... e questo secondo me non può che essere un bene!!!!

Qualche sviluppatore(soprattutto in passato, ma ancora oggi si tende a fare così perché diminuisce notevolmente la mole di lavoro) pensava di prendere la "scorciatoia" e per stilare il PMS ha pensato bene di "constatare l'attuale comportamento del portage" e di documentare tale comportamento dentro il PMS. Il problema, anche se a molti di voi sembrerà assurdo, è che non si riesce a capire fino in fondo e con precisione quale comportamento assume emerge(allo stato attuale) in determinate situazioni, con quale criterio lavora etc... Quando è venuto fuori il problema degli mtimes, la prima cosa che si è pensato di fare è proprio questa(ossia descrivere l'attuale comportamento di emerge), ma con scarsi risultati.

Qualcuno in ML ha anche sostenuto(a ragione secondo me) che l'approccio "cerca di documentare l'attuale comportamento del portage e fanne uno standard" è lo stesso adottato da OOXML di microsoft(per lo standard in questione) e dovrebbe essere abolito per le stesse ragioni. Quella più intuitiva è che tale approccio rende incompleta la specifica, per cui se qualcuno riscrivesse un software alla cieca(seguendo e rispettando solo la specifica) ne risulterebbe un software non "del tutto" compatibile con portage (ne tantomeno coerente col suo comportamento).

Vediamo come si evolverà la situazione e speriamo nel meglio...

Edit: errore grammaticale

----------

## !equilibrium

per chi fosse interessato, è stato reso pubblico l'url del sito di testing per la nuova veste grafica di znurt.org (aka packages.gentoo.org); buona visione a tutti.

p.s.: qui l'annuncio ufficiale.

----------

## cloc3

 *!equilibrium wrote:*   

> per chi fosse interessato, è stato reso pubblico l'url del sito di testing

 

fantastico.

persino la ricerca funziona.

solo. ho notato che, facendo una ricerca del tipo app-misc/ genera una pagina di difficile lettura e piuttosto pesante (il mouse scorre a scatti sul konqueror del mio aspireOne). dovrebbero modificare il layout per le ricerche che producono un numero di risposte superiore ad un certo limite stabilito.

----------

## lucapost

Trovo già ottimo l'attuale packages.gentoo.org. Essendo abbastanza chiaro e compatto la sua consultazione risulta a me molto più rapida che la nuova interfaccia. Non vedo dunque il bisogno di dover implementarne un'ulteriore.

----------

## !equilibrium

 *cloc3 wrote:*   

> solo. ho notato che, facendo una ricerca del tipo app-misc/ genera una pagina di difficile lettura e piuttosto pesante (il mouse scorre a scatti sul konqueror del mio aspireOne). dovrebbero modificare il layout per le ricerche che producono un numero di risposte superiore ad un certo limite stabilito.

 

buona osservazione, riportala al devel in questione

----------

## lordalbert

 *lucapost wrote:*   

> Trovo già ottimo l'attuale packages.gentoo.org. Essendo abbastanza chiaro e compatto la sua consultazione risulta a me molto più rapida che la nuova interfaccia. Non vedo dunque il bisogno di dover implementarne un'ulteriore.

 

a me la nuova interfaccia sembra decisamente migliore. Sia dal punto di vista estetico, che funzionale. Poi, un packages.gentoo.org senza una degna funzione di ricerca... mi sembra un po' inutile.

----------

## cloc3

 *!equilibrium wrote:*   

> 
> 
> buona osservazione, riportala al devel in questione

 

ci ho provato, ma non è così banale.

sembrerebbe che, per contattare lo sviluppatore, sia necessario utilizzare strumenti personali, come la chat, l'indirizzo mail, il canale irc o l'account twitter.

al contrario, la mia osservazione è di un genere che dovrebbe essere collocato in uno spazio pubblico, tipo bugzilla.

se non altro perché non ho detto nulla di così originale che non possa essere stato riscontrato da altri, e troverei dispersivo martellare lo sviluppatore con l'ennesima ripetizione della stessa richiesta.

p.s.: ho osservato che la vera causa del rallentamento di cui parlo sopra dipende dalla lentezza della mia rete locale.

questo, però, non diminuisce l'opportunità di alleggerire la pagina.

----------

