# GeCHI Weekly Report #1.5

## oRDeX

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

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

[1] Rimozione del profilo 'default-linux' (22.10)

I profili Gentoo presenti in default-linux/ verrano definitivamente rimossi dal tree di portage entro dicembre 2009; gli utenti che fanno ancora uso di tali profili obsoleti sono incoraggiati a migrare a quelli nuovi, onde evitare di ritrovarsi portage con funzionalità molto limitate.

[2] KDE Team Meeting (22.10)

Lo scorso 22 ottobre si è tenuto il meeting mensile tra gli sviluppatori del Gentoo KDE Project per discutere i seguenti punti:

1. proposta di suddividere il profilo desktop in sotto-profili - la proposta verte sul fatto che molti utenti vogliono solo Gnome o KDE e non entrambi, quindi l'attuale profilo desktop non funziona bene per questi utenti e la creazione di due nuovi profili separati (desktop/kde e desktop/gnome) che derivano da un generico profilo base (desktop/base) potrebbe essere una buona soluzione al problema; la proposta ha avuto esito favorevole e verrà discussa nella mailing list @gentoo-dev per i dettagli di implementazione;

2. discussione delle politiche di split per gli ebuild di KDE4 - la proposta riguarda l'ulteriore suddivisione di alcuni pacchetti di KDE4 per meglio saparare le librerie dalla relativa applicazione, come è stato fatto di recente per kdepim; pacchetti come, per esempio kdm, verrebbero quindi separati in kde-base/kdmlibs e kde-base/kdm, ma visto che alcuni membri del team KDE erano assenti, si è rimandata la discussione di questo argomento alla mailing list di KDE;

3. nuovo sotto-progetto Qt per il Gentoo Desktop Project - siccome il team di sviluppatori di Qt è separato da quello di KDE si è deciso che è il caso di separarli anche dal punto di vista dei progetti (Qt != KDE) e quindi sarà creata una nuova sezione web specifica tra i vari progetti Gentoo;

4. nuove politiche per i rilasci di KDE (beta/rc) - alcuni sviluppatori del Team KDE hanno sollevato la richiesta di inserire le versioni non rilasciate ufficialmente di Qt e KDE (beta, rc, live) direttamente nel tree di portage (masked) anzichè come avviene ora tramite l'overlay kde-testing; la proposta è stata rigettata perchè la maggioranza preferisce l'attuale situazione;

5. proposta di ritornare agli ebuild monolitici per Qt - tale proposta è stata sollevata per risolvere alcuni problemi che affliggono gli utenti inesperti che non sanno installare Qt 4.5.x correttamente, ma da tale discussione è emerso che la proposta non è la soluzione al problema perchè è più un difetto di emerge che non gestisce correttamente le dipendenze di Qt (devono essere tutte minor release uguali) che un problema degli ebuild in se, quindi la discussione è stata rimandata alla prossima riunione od ad una discussione in mailing list @gentoo-dev con il supporto del team di sviluppo di portage per avere le modifiche necessarie;

6. pianificazione della rimozione delle vecchie versini di Qt (<=4.5.2:4) - pianificazione rimandata a causa del fatto che per le arch sparc e ppc non è possibile marcare stabile la versione 4.5.3:4 per via di bug di compilazione ancora pendenti;

[3] virtualx.eclass (20.10)

Di recente è stata modificata l'eclass virtualx.eclass per correggere alcuni errori riguardanti le dipendenze x11-base/xorg-server e x11-apps/xhost relative alla USE flag X. L'effetto di questa modifica è stata la rimozione della USE X per alcuni pacchetti con conseguente eliminazione del pacchetto x11-base/xorg-server dal world; se il comando emerge -p --depclean vi vuole rimuovere il pacchetto x11-base/xorg-server, aggiungetelo manualmente al file world (echo "x11-base/xorg-server" >> /var/lib/portage/world).

[4] nuova multilib ABI per portage (11.10)

Storicamente Gentoo ha sempre avuto la possibilità di eseguire applicazioni 32bit su un'installazione a 64bit della distribuzione grazie ai profili multilib, ma sfortunatamente questa soluzione non è mai stata ottimale e si porta dietro degli svantaggi non indifferenti, quali, per esempio:

l'impossibilità di passare in modo agevole da un profilo no-multilib ad uno multilib;i pacchetti emul-linux-x86-* hanno cicli di rilascio molto più lenti dei corrispettivi pacchetti standard con conseguenti problematiche quali instabilità e scarsa completezza delle librerie installate;

Ecco dunque che il Team di sviluppatori Gentoo ha pensato di creare una nuova ABI per il supporto multilib che permetta di installare nativamente applicazioni 32bit in un'installazione a 64bit, senza bisogno di utilizzare i pacchetti emul-linux-x86-*; la parola chiave è ovviamente: nativamente, perchè la nuova ABI permetterà di sostituire completamente i pacchetti emul-linux-x86-* presenti in portage con quelli nativi del tree di Portage. Ciò sarà possibile grazie all'introduzione di una nuova eclass: /usr/portage/eclass/multilib-native.eclass, la quale aggiungerà una nuova USE flag chiamata: lib32; se l'utente avrà bisogno del supporto a 32bit per un determinato pacchetto non dovrà far altro che abilitare la USE lib32 e in automatico emerge eseguirà due fasi di compilazione, una a 64bit e una a 32bit, permettendo in questo modo di installare nativamente, oltre alla versione a 64bit, anche la versione a 32bit delle librerie del pacchetto, con tutti i vantaggi che ne derivano e senza gli svantaggi generati dai precompilati di emul-linux-x86.

Questa nuova multilib ABI è attualmente ancora un lavoro in corso, i cui sforzi si stanno concretizzando nell'overlay multilib-overlay (layman -a multilib); qui di seguito un esempio dell'output di emerge dopo l'aggiunta del suddetto overlay:

```
# emerge -auDNv --with-bdeps y world

These are the packages that would be merged, in order:

Calculating dependencies   ........ .. .... ... ..... ........ .. ... done!

[ebuild  N    ] sys-apps/abi-wrapper-1.0-r2  0 kB [1]

[ebuild   R   ] dev-util/pkgconfig-0.23  USE="-hardened -lib32%" 0 kB [0=>1]

[ebuild   R   ] sys-libs/zlib-1.2.3-r1  USE="-lib32%" 0 kB [0=>1]

[ebuild   R   ] sys-libs/ncurses-5.6-r2  USE="unicode -debug -doc -gpm -lib32% -minimal -nocxx -profile -trace" 0 kB [0=>1]

[ebuild   R   ] dev-libs/expat-2.0.1-r2  USE="-lib32%" 0 kB [0=>1]

[ebuild   R   ] app-arch/bzip2-1.0.5-r1  USE="-lib32% -static" 0 kB [0=>1]

[ebuild   R   ] sys-libs/cracklib-2.8.13  USE="nls -lib32% -python" 0 kB [0=>1]

[ebuild   R   ] dev-libs/libffi-3.0.8  USE="-debug -lib32% -static-libs -test" 0 kB [0=>1]

[ebuild  N    ] app-arch/lzma-utils-4.32.7  USE="-lib32% -nocxx" 0 kB [0=>1]

[ebuild   R   ] app-text/libpaper-1.1.23  USE="-lib32%" 0 kB [0=>1]

[ebuild   R   ] media-libs/openjpeg-1.3-r2  USE="-lib32% -tools" 0 kB [0=>1]

[ebuild   R   ] media-libs/ilmbase-1.0.1  USE="-lib32%" 0 kB [0=>1]

[ebuild   R   ] media-libs/faad2-2.7  USE="-digitalradio -lib32%" 0 kB [0=>1]

[ebuild   R   ] dev-libs/libsigc++-2.2.3  USE="-debug -doc -lib32% -test" 0 kB [0=>1]

[ebuild   R   ] dev-db/sqlite-2.8.16-r4  USE="nls -doc -lib32% -tcl" 0 kB [0=>1]

```

L'aggiunta della nuova eclass multilib-native e il supporto da parte di portage delle doppie ebuild phase[/URL] dovevano essere discusse durante il Gentoo Council di ottobre tenutosi il 12.10, ma l'argomento non è stato inserito nell'agenda del meeting per tempo utile, quindi la discussione è stata rimandata al prossimo Gentoo Council di novembre.

[5] rimozione di Qt:3 e KDE:3 da portage (20.10)

E' in procinto la rimozione di KDE:3 e tutte le sue dipendenze dal tree di portage, compreso x11-libs/qt:3; tali pacchetti verranno spostati nell'overlay kde-sunset.

[last rites]

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

# Samuli Suominen (ssuominen [at] entoo.org) (16 Oct 2009)

# Fails to build with KDE4 installed wrt bug #277427.

# Masked for removal in 30 days.

net-news/eventwatcher

# Samuli Suominen (ssuominen [at] entoo.org) (16 Oct 2009)

# Fails to build with KDE4 installed wrt bug #277417.

# Masked for removal in 30 days.

kde-misc/kisdnwatch

# Samuli Suominen (ssuominen [at] entoo.org) (16 Oct 2009)

# Fails to build with KDE4 installed wrt bug #277415.

# Masked for removal in 30 days.

net-ftp/kasablanca

# Samuli Suominen (ssuominen [at] entoo.org) (16 Oct 2009)

# Fails to build with KDE4 installed wrt bug #277172.

# Masked for removal in 30 days.

net-misc/ktraynetworker

# Samuli Suominen (ssuominen [at] entoo.org) (16 Oct 2009)

# Fails to build with KDE4 installed wrt bug #276891.

# Masked for removal in 30 days.

x11-themes/activeheart-kwin

# Samuli Suominen (ssuominen [at] entoo.org) (16 Oct 2009)

# Fails to build with KDE4 installed wrt bug #276876.

# Masked for removal in 30 days.

app-office/kbudget

# Samuli Suominen (ssuominen [at] entoo.org) (16 Oct 2009)

# Fails to build with KDE4 installed wrt bug #276851.

# Masked for removal in 30 days.

app-backup/konserve

# Samuli Suominen (ssuominen [at] entoo.org) (16 Oct 2009)

# Fails to build with KDE4 installed wrt bug #276205.

# Masked for removal in 30 days.

x11-themes/comix

# Samuli Suominen (ssuominen [at] entoo.org) (16 Oct 2009)

# Fails to build with KDE4 installed wrt bug #248883.

# Masked for removal in 30 days.

kde-misc/kdirstat

# Samuli Suominen  gentoo.org> (16 Oct 2009)

# Fails to build with KDE4 installed wrt bug #278628.

# Masked for removal in 30 days.

media-sound/krecord

# Samuli Suominen (ssuominen [at] entoo.org) (20 Oct 2009)

# Doesn't compile with Qt4 installed wrt bug #275316.

# Masked for removal in 30 days.

net-im/sim

# Samuli Suominen (ssuominen [at] entoo.org) (20 Oct 2009)

# Doesn't compile with KDE4 installed wrt bug #279297.

# Masked for removal in 30 days.

games-board/kwappen

# Samuli Suominen (ssuominen [at] entoo.org) (20 Oct 2009)

# Doesn't compile with KDE4 installed wrt bug #279659.

# Masked for removal in 30 days.

kde-misc/ksystemlog

# Samuli Suominen (ssuominen [at] entoo.org) (20 Oct 2009)

# Doesn't compile with KDE4 installed wrt bug #279486.

# Masked for removal in 30 days.

media-tv/mtvg

# Samuli Suominen (ssuominen [at] entoo.org) (19 Oct 2009)

# KDE3-only and doesn't compile, bug #246783.

# Removed in 30 days.

kde-misc/kdissert

# Samuli Suominen (ssuominen [at] entoo.org) (17 Oct 200)

# Obsolete Musepack SV7 format support. Install

# media-sound/musepack-tools for libs and tools to convert

# your audio files to SV8 format.

media-libs/libmpcdec

# Michael Sterrett (mr_bones_ [at] entoo.org) (19 Oct 2009)

# Homepage is gone; requires dev-python/numeric; last released in 2006

games-rpg/galaxymage

# Diego E. Pettenò (flameeyes [at] entoo.org) (21 Oct 2009)

# Upstream deprecated it, so we're going to get rid of it in 30 days; use

# pavucontrol and paprefs to do what paman did.

media-sound/paman

# Raúl Porcel (armin76 [at] entoo.org) (22 Oct 2009)

# Not needed anymore, vanilla kernel works

# pretty well on SH nowadays.

# Removal in 30 days

sys-kernel/sh-sources

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;Digg: GeCHI Group | GeCHI RSS FeedsFacebook;Last edited by oRDeX on Sat Oct 24, 2009 5:49 pm; edited 3 times in total

----------

## cloc3

 *oRDeX wrote:*   

> Ciò sarà possibile grazie all'introduzione di una nuova eclass: /usr/portage/eclass/multilib-native.eclass, la quale aggiungerà una nuova USE flag chiamata: lib32; se l'utente avrà bisogno del supporto a 32bit per un determinato pacchetto non dovrà far altro che abilitare la USE lib32
> 
> 

 

uno dei problemi che riscontro, legati ai bisticci 32bit versus 64, è legato alla compatibiità con certi codec nascosti dentro i filmati .wmv .

sarà possibile, usando correttamente questi strumenti, utilizzare mplayer a 32 bit esclusivamente per filmati di questo tipo?

----------

## !equilibrium

 *cloc3 wrote:*   

> uno dei problemi che riscontro, legati ai bisticci 32bit versus 64, è legato alla compatibiità con certi codec nascosti dentro i filmati .wmv. sarà possibile, usando correttamente questi strumenti, utilizzare mplayer a 32 bit esclusivamente per filmati di questo tipo?

 

se mplayer su un'installazione a 32bit ti legge correttamente quei filmati, allora sì; se invece il problema è intrinseco ai codec (che non esistono per linux o perchè sono varianti non documentate di quelli standard) puoi anche usare tutte le architetture esotiche che vuoi, ma il filmato non lo vedrai ugualmente.

----------

## lordalbert

addirittura rimuovere kde3?   :Shocked: 

E' vero che ora c'è il 4, ma credo ci sia ancora gente che voglia rimanere al più stabile 3. Io lo avrei lasciato ancora un po..

----------

## Apetrini

 *lordalbert wrote:*   

> addirittura rimuovere kde3?  
> 
> E' vero che ora c'è il 4, ma credo ci sia ancora gente che voglia rimanere al più stabile 3. Io lo avrei lasciato ancora un po..

 

Infatti non lo rimuovono, lo spostano in un overlay (kde-sunset).

----------

## cloc3

 *Apetrini wrote:*   

> 
> 
> Infatti non lo rimuovono, lo spostano in un overlay (kde-sunset).

 

è la stessa cosa.

per me, questa smania di abbandonare kde3 è un autogol enorme del software libero.

@!equilibrium: sì: quei codec funzionano con mplayer a 32bit ma non a 64.

----------

## canduc17

Non ho capito sta storia del profilo default: *Quote:*   

> [1] Rimozione del profilo 'default-linux' (22.10)
> 
> I profili Gentoo presenti in default-linux/ verrano definitivamente rimossi dal tree di portage entro dicembre 2009; gli utenti che fanno ancora uso di tali profili obsoleti sono incoraggiati a migrare a quelli nuovi, onde evitare di ritrovarsi portage con funzionalità molto limitate.

 Una settimana fa è apparsa una news, visibile se ci si accingeva ad aggiornare world, che bisognava passare ad un profilo 10.0, perchè il 2008.0 non sarebbe più stato supportato. Allora ho aggiornato alla prima di queste voci

```
canduc@candell ~ $ eselect profile list

Available profile symlink targets:

  [1]   default/linux/amd64/10.0 *

  [2]   default/linux/amd64/10.0/desktop

  [3]   default/linux/amd64/10.0/developer

  [4]   default/linux/amd64/10.0/no-multilib

  [5]   default/linux/amd64/10.0/server

  [6]   hardened/linux/amd64/10.0

  [7]   hardened/linux/amd64/10.0/no-multilib

  [8]   selinux/2007.0/amd64

  [9]   selinux/2007.0/amd64/hardened

  [10]  selinux/v2refpolicy/amd64

  [11]  selinux/v2refpolicy/amd64/desktop

  [12]  selinux/v2refpolicy/amd64/developer

  [13]  selinux/v2refpolicy/amd64/hardened

  [14]  selinux/v2refpolicy/amd64/server
```

Perchè dovrebbero togliere la branca default? E se io volessi un sistema ibrido, nè desktop, nè server?!

Mi sembra un'errore nel riportare la notizia...

----------

## Apetrini

 *cloc3 wrote:*   

> 
> 
> è la stessa cosa.
> 
> per me, questa smania di abbandonare kde3 è un autogol enorme del software libero.
> ...

 

Non è la stessa cosa, mi sembra evidente, la cancellazione totale anche dall'overlay impedisce l'installazione di kde3.

La questione di scindere alcune cose negli overlay, mi trova perfettamente d'accordo. Se fosse per me sposterei i 2 DE piu grossi (gnome e kde4) in altri 2 overlay esterni. Tenere un portage tree grosso grosso non ha senso; mi dite perché uno che ha un profilo server deve per forza avere nel portage anche gli ebuild di roba "chiaramente più orientata al desktop" ?

E poi guardando al futuro, bisognerà pur scindere alcune cose; il mega calderone tutto incluso è scomodo.

Voglio dire gli overlay sono fatti anche per questo. Non per forza devono essere distaccati da quello che sono i progetti gentoo, possono essere gestiti a livello ufficiale.

Se poi il problema è al livello psicologico dell'utente, questo è un altro discorso...

P.s. se poi non siete convinti di come vengano gestiti gli overlay a livello di sistema, ne possiamo parlare...

----------

## canduc17

Non sono d'accordo: io trovo scomodi gli overlay.

Se vuoi escludere parti del tree, fai in questo modo.

----------

## !equilibrium

 *Apetrini wrote:*   

> mi dite perché uno che ha un profilo server deve per forza avere nel portage anche gli ebuild di roba "chiaramente più orientata al desktop" ?

 

emerge oramai ha già il pieno supporto agli overlay git, ma sfortunamente non esistono ancora i repository ufficiali git di portage; al momento è ancora un WIP per via dei grossi cambiamenti strutturali che sono richiesti, ma prima o poi la questione "portage monolotico vs overlay" sarà tutta a favore di quest'ultimo (ma non ti so dare stime precise sulle tempistiche).

 *Apetrini wrote:*   

> Voglio dire gli overlay sono fatti anche per questo. Non per forza devono essere distaccati da quello che sono i progetti gentoo, possono essere gestiti a livello ufficiale.

 

gli overlay che ho citato nel GWR sono overlay git ufficiali gentoo, li trovate tutti qui e quindi sono mantenuti dai devel gentoo.

 *canduc17 wrote:*   

> Non sono d'accordo: io trovo scomodi gli overlay.
> 
> Se vuoi escludere parti del tree, fai in questo modo.

 

non è una soluzione ideale, ogni volta che viene aggiunto/tolto qualcosa in portage devi modificare i parametri di rsync, senza contare il fatto che non puoi omettere tutto x11-libs/ o altre directory perchè ci stanno pacchetti di Xorg che hai bisogno comunque anche su un server, quindi sei costretto a filtrare praticamente singolo pacchetto per singolo pacchetto; decisamente un NO come soluzione, pena la sanità mentale dell'amministratore di sistema che se ne va del tutto.

----------

## !equilibrium

 *canduc17 wrote:*   

> Perchè dovrebbero togliere la branca default? E se io volessi un sistema ibrido, nè desktop, nè server?!
> 
> Mi sembra un'errore nel riportare la notizia...

 

la notizia parla del profilo default-linux/, non del profilo default/, in portage ci sono 3 tipologie di profili 'default':

 *Quote:*   

> ls /usr/portage/profiles/def*
> 
> default   
> 
> default-bsd
> ...

 

----------

## lucapost

 *oRDeX wrote:*   

> [4] nuova multilib ABI per portage (11.10)

 

ci saranno novità per gli utenti che utilizzano un profilo no-multilib per quello che riguarda pacchetti binari come skype e acroread?

----------

## canduc17

 *!equilibrium wrote:*   

> a notizia parla del profilo default-linux/, non del profilo default/, in portage ci sono 3 tipologie di profili 'default'

 Ok, adesso ho capito.

 *!equilibrium wrote:*   

> non è una soluzione ideale, ogni volta che viene aggiunto/tolto qualcosa in portage devi modificare i parametri di rsync, senza contare il fatto che non puoi omettere tutto x11-libs/ o altre directory perchè ci stanno pacchetti di Xorg che hai bisogno comunque anche su un server, quindi sei costretto a filtrare praticamente singolo pacchetto per singolo pacchetto; decisamente un NO come soluzione, pena la sanità mentale dell'amministratore di sistema che se ne va del tutto.

 Okkey per le cose importanti come x11-libs, ma ad esempio a me non frega una cippa dei giochi e di xfce e mettendo in /etc/portage/rsync_excludes

```
games-*/*

xfce-*/*
```

sto da dio da diversi anni...

----------

## !equilibrium

 *cloc3 wrote:*   

> per me, questa smania di abbandonare kde3 è un autogol enorme del software libero.

 

tenete anche presente che qt:3 non è più sviluppato da nokia e ci sono un sacco di bug aperti che non verranno più risolti quindi non ha molto senso continuare a sviluppare anche kde:3 perchè per farlo vorrebbe dire essere obbligati a fare il porting a qt:4; ha senso fare un kde:3 basato su qt:4 quando esiste già kde:4?   :Smile: 

 *lucapost wrote:*   

>  *oRDeX wrote:*   [4] nuova multilib ABI per portage (11.10) 
> 
> ci saranno novità per gli utenti che utilizzano un profilo no-multilib per quello che riguarda pacchetti binari come skype e acroread?

 

bella domanda!

da quello che ho capito io, con la nuova ABI, non dovrebbe più esserci incompatibilità tra il profilo no-multilib e multilib, anzi, il profilo no-multilib dovrebbe sparire visto che diventerà il default per le installazioni a 64bit; poi se avrai bisogno di usare applicazioni a 32bit ti basterà abilitare la use 'lib32' dove necessario; quindi per skype e pacchetti precompilati del genere, verranno modificati gli ebuild affinchè richiedano esplicitamente la use 'lib32' sulle dipendenze.

p.s.: siete incoraggiati a fare test con l'overlay e mandare i vari feedback al devel gentoo che lo gestisce  :Wink:  così velocizziamo un po lo sviluppo.

----------

## Scen

 *oRDeX wrote:*   

> [4] nuova multilib ABI per portage (11.10)
> 
> Storicamente Gentoo ha sempre avuto la possibilità di eseguire applicazioni 32bit su un'installazione a 64bit della distribuzione grazie ai profili multilib, ma sfortunatamente questa soluzione non è mai stata ottimale e si porta dietro degli svantaggi non indifferenti, quali, per esempio:
> 
> l'impossibilità di passare in modo agevole da un profilo no-multilib ad uno multilib;i pacchetti emul-linux-x86-* hanno cicli di rilascio molto più lenti dei corrispettivi pacchetti standard con conseguenti problematiche quali instabilità e scarsa completezza delle librerie installate;
> ...

 

MERAVIGLIOSO   :Cool: 

Overlay aggiunto, sto già provando a ricompilare il sistema! Vediamo come và   :Razz: 

----------

## oRDeX

 *Scen wrote:*   

>  *oRDeX wrote:*   [b][4] nuova multilib ABI per portage (11.10)[/b 
> 
> MERAVIGLIOSO  
> 
> Overlay aggiunto, sto già provando a ricompilare il sistema! Vediamo come và  

 

Nessuno che usi wine che stia provando anche l'overlay multilib? Io mi sto ritrovando tonnellate di librerie da ricompilare con lib32...e mi pare anche ovvio dato che wine emula il sistema a 32 bit..ma la cosa è decisamente fastidiosa...

----------

