Ieri si è svolto il primo Bug Day organizzato dal Gruppo Sviluppo (ed in particolar modo da Andrea Gasparini). Come da programma, ci si è occupati dei bug “Fix committed” e dei fastidiosi “trying to overwrite a file“.

Anche se l’evento era una “prova generale” per organizzare un incontro più strutturato e con una partecipazione maggiore (si pensava di organizzare qualcosa a Bologna in primavera), i risultati sono stati positivi: più di quaranta bug affrontati e risolti, diverse patch allegate su Launchpad e un paio di pacchetti caricati negli archivi.

Un buon punto di partenza per fare meglio in futuro, tutti sono invitati!

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Ora che Intrepid è stata rilasciata, è tempo di analizzare i suoi numeri.

I numeri belli…

• 15133 pacchetti sorgente
• 26847 pacchetti .deb
• 9409 aggiornamenti
• 5323 bug corretti

… e quelli un po’ meno belli

• 81 pacchetti con problemi di compilazione
• 30 pacchetti non installabili
• 50698 bug aperti

La classifica
Come tradizione vuole, ecco l’elenco dei quindici sviluppatori più attivi durante il ciclo di sviluppo di Intrepid:
1     Jonathan Riddell (660 packages)
2     Sebastien Bacher (477 packages)
3     Colin Watson (406 packages)
4     Matthias Klose (362 packages)
5     Luca Falavigna (361 packages)
6     Martin Pitt (317 packages)
7     Michael Vogt (305 packages)
8     Harald Sitter (250 packages)
9     Timo Aaltonen (231 packages)
10    Steve Kowalik (228 packages)
11    Michael Bienia (227 packages)
12    Nathan Handler (185 packages)
13    Cesare Tirabassi (168 packages)
14    Stefan Ebner (150 packages)
15    Scott Kitterman (133 packages)

Il sottoscritto occupa la quinta piazza, non male

Made in Italy
Questi sono i pacchetti realizzati dai membri della comunità italiana:
5      Luca Falavigna (361 packages)
25    Devid Antonio Filoni (96 packages)
70    Alessio Treglia (25 packages)
85    Andrea Gasparini (18 packages)
88    Andrea Colangelo (16 packages)
89    Riccardo Coccioli (16 packages)
128  Salvatore Palma (8 packages)
139  Matthew East (5 packages)
161  Alessandro Ghersi (3 packages)
189  Paolo Naldini (2 packages)

Facce note, ma anche qualche novità tra le quali spiccano un amministratore del Wiki e uno del forum, se avete notato qualche rallentamento o malfunzionamento nei servizi sopra citati, è probabile che i responsabili fossero impegnati a fare pacchi

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

… a dir la verità non c’è niente di bello, e a dirla tutta non si tratta nemmeno di Free Software.

Nelle note di rilascio di Intrepid si legge quanto segue:

I driver della serie 71 e 96 dei driver proprietari nVidia, forniti dai pacchetti nvidia-glx-legacy e nvidia-glx in Ubuntu 8.04 non sono compatibili con la versione di X.Org inclusa in Ubuntu 8.10. Gli utilizzatori delle schede con chipset nVidia TNT, TNT2, TNT Ultra, GeForce, GeForce2, GeForce3 e GeForce4 saranno reinoltrati al driver libero nv, il quale non fornisce l’accelerazione 3D.

Gli utenti dei chipset nVidia supportati dalle serie 173 o 177 saranno reinoltrati ai pacchetti nvidia-glx-173 o nvidia-glx-177. A differenza dei driver delle serie 71 e 96, sono compatibili con i processori con supporto SSE (Intel Pentium III, AMD Athlon XP or più recenti). Sistemi con processori meno recenti saranno reindirizzati al driver nv.

Per farla breve, per alcuni utenti il passaggio a Intrepid non garantirà il supporto all’accelerazione 3D, il che non permetterà di poter godere di alcune funzionalità alquanto utili (… “sezione da riempire, si accettano suggerimenti” …) o altrettanto inutili (compiz, compiz, l’ho già scritto compiz?).

Tutto questo non mi tocca minimamente non facendo uso di tali driver, quello che mi dispiace è sentire il commento di parecchi utenti che battezzano Intrepid come “nata male” (verrà rilasciata il prossimo giovedì, per la cronaca…) perchè un software proprietario non è compatibile con una o più applicazioni alla base della nuova release. Evitiamo di dare giudizi affrettati sul lavoro di persone che, nel bene o nel male, cercano di fornire una distribuzione usabile nei tempi prestabiliti, e se proprio vogliamo incolpare qualcuno, il ditino dovrebbe essere puntato verso i produttori del software proprietario in questione, in quanto solo loro possono mettere mano al codice.

Il Free Software è bello perchè tutto quello che uso quotidianamente su Intrepid funziona, ed è tutto Software Libero.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Il secondo Ubuntu-it meeting, svoltosi a Cesenatico, è stato un successone! Ottimi talk, platea partecipe e preparata e, non per ultimo, tantissimi momenti trascorsi insieme ai fantastici membri della comunità italiana. Un weekend praticamente perfetto, difficilmente potrò dimenticare questa esperienza meravigliosa. Ciliegina sulla torta è stata la presentazione del sistema Virtual Square da parte del prof. Davoli, il quale mi ha letteralmente entusiasmato (spero che non mi abbiano immortalato mentre stavo sbavando contemplando le potenzialità del progetto).

Oltre ai discorsi prettamente tecnici, mi sono reso conto che:

• Jeremie riesce a mangiare una piadina romagnola in meno di un minuto
• Lorenzo e il sottoscritto hanno problemi di vescica (i nostri ripetuti appostamenti nei pressi del bagno della trattoria di Cervia ne sono una prova)
• Caricare notebook sulla mia macchina può causare imprevisti con le coincidenze dei treni
• Il Cane mi ha mangiato il Certificato, forse non lo nutro a sufficienza?

Quante cose si scoprono ad un meeting di Ubuntu-it

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Qualche giorno fa ho presentato la mia candidatura per colmare il posto vacante di release manager per Universe. Dopo le 168 ore di attesa previste dalla policy, sono stato aggiunto al team motu-release per poter coordinare il rilascio di Intrepid per le componenti Universe e Multiverse!

Un ringraziamento a Stefan, Cesare e Nicolas per il supporto. E ora… al lavoro!

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

… ovvero come fare tanta bua a Unstable, Hardy e Intrepid senza nemmeno rendersi conto di cosa sta succedendo.

Mi è capitato per le mani il bug #255819, nel quale viene descritta una procedura composta da tre comandi all’apparenza innocui che, per un errore di programmazione, innescano il comando più amato/odiato dagli utenti UNIX:

1. sudo apt-get install slack
2. : > /etc/slack.conf
3. sudo apt-get –purge remove slack

Il problema viene innescato dal prerm di slack, lo script che si occupa di eseguire comandi prima di effettuare la rimozione di un determinato pacchetto. In tale script, si tenta di includere le variabili del file di configurazione di slack per mezzo dell’istruzione . /etc/slack.conf, in seguito viene richiamato il comando rm -rf “$CACHE”/* , il quale si occupa di ripulire le cache di slack. Nel caso il file di configurazione di slack sia vuoto, “$CACHE”/* si espande semplicemente in / e il fatidico rm -fr / viene eseguito!

La patch, già disponibile in un pacchetto aggiornato in Unstable, a breve anche per Intrepid e Hardy (via -updates), effettua un controllo su $CACHE prima di eseguire il comando successivo. Se è vuota, nulla viene eseguito e il sistema è salvo. Se siete utilizzatori di slack, provvedete quanto prima all’aggiornamento alla versione 0.14.1-3 (Unstable e Intrepid) o 0.14.1-2ubuntu1 (Hardy) per non correre rischi.

P.S. Stranamente il pacchetto capace di mandare a quel paese Debian e derivate si chiama slack… i vecchi conflitti (quasi religiosi, a volte) con Slackware sono sempre d’attualità

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Il Feature Freeze, previsto per il 28 agosto, si avvicina a grandi passi. Dopo quella data, ci si concentrerà sui dettagli e nella risoluzione di bug più o meno gravi che affliggono quella che, a ottobre, diventerà Ubuntu 8.10.

La strada è ancora lunga e ci sono tanti piccoli dettagli da sistemare, anche il più piccolo contributo è apprezzato e permette di avvicinarsi sempre di più al rilascio. Elenco brevemente qualche attività di Quality Assurance su cui chiunque può cimentarsi, basta solo un po’ di tempo e voglia di imparare.

Ripulire gli archivi dagli NBS
Una delle attività più semplici è la rimozione dagli archivi dei pacchetti obsoleti attraverso la ricompilazione dei pacchetti con dipendenze inverse. Un ottimo articolo di Andrea Colangelo spiega brevemente come gestire i casi più comuni.

Importare i bugfix da Debian
Debian svolge un ottimo lavoro di manutenzione dei propri pacchetti. Dopo il Debian Import Freeze si cessa di importare automaticamente le nuove revisioni per iniziare la fase di stabilizzazione degli archivi. Questo ha i suoi ovvi vantaggi, ma dall’altro lato si perde la possibilità di incorporare fix importanti. Questo strumento elenca i bug importanti risolti in Debian ma non ancora importati in Ubuntu, ogni bug elencato dovrebbe essere chiuso anche in Ubuntu prima del rilascio.

Gestire i problemi nei vari pacchetti
Debcheck è un ottimo strumento per avere un colpo d’occhio immediato sui pacchetti che hanno problemi. Dipendenze non soddisfatte, problemi di priorità e ogni altro problema elencato dovrebbe essere gestito al meglio prima del rilascio per avere il maggior numero di pacchetti installabili.

Risolvere i problemi di compilazione
Anche se spesso servono conoscenze specifiche, dare una mano nel risolvere i problemi di compilazione dei pacchetti è importantissimo. Avere tutti i pacchetti compilati correttamente in Intrepid è sicuramente un obiettivo difficile, ma con un po’ di impegno gran parte dei problemi si possono risolvere prima del rilascio.

Varie ed eventuali
Questa è solo una carrellata di quello che si può fare per migliorare Intrepid. Per un elenco più approfondito, si veda questa pagina: http://qa.ubuntuwire.com.

Happy hacking!

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Tra gli aggiornamenti di oggi in Intrepid, vi è anche una nuova revisione di ubuntu-meta:

ubuntu-meta (1.106) intrepid; urgency=low

  * Refreshed dependencies
  * Added rarian-compat to desktop
  * Removed scrollkeeper from desktop
  * Removed sound-juicer from desktop-recommends

 -- Martin Pitt <martin.pitt@ubuntu.com>  Thu, 17 Jul 2008 10:33:30 +0100

Da anni combatto una guerra personale contro scrollkeeper, quel coso maledetto pacchetto impiega un tempo variabile dai ventisette minuti alla mezz’ora abbondante per terminare la configurazione sul mio sistema, il che mi rende un tantino nervoso (soprattutto durante una compilazione importante).

Scrollkeeper è stato sostituito da rarian, spero tanto che sia meno avido di tempo processore, già ne ho carenza e non mi va di sprecarlo. Un ringraziamento a Martin Pitt per aver reso tutto questo possibile

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Ma tu guarda che mi tocca vedere…

A volte i computer sono strani, fanno cose che non ti aspetti e cercare di capirli è impossibile o quasi. Uno di questi casi è il bug #482079, ci sono capitato per caso mentre tentavo di risolvere un problema di compilazione del pacchetto highlighting-kate, che falliva a causa di un errore di configurazione in libghc6-pcre-light-dev:

Setting up libghc6-pcre-light-dev (0.3.1-3) ...
Reading package info from "/usr/lib/haskell-packages/ghc6/lib/pcre-light-0.3.1/installed-pkg-config" ... ghc-pkg: 15: unrecognised field or section: "<http://code.haskell.org/~dons/tests/pcre-light/hpc_index.html>”
dpkg: error processing libghc6-pcre-light-dev (–configure):
subprocess post-installation script returned error exit status 1

Dopo aver inutilmente cercato di trovare una soluzione razionale al problema, ho fatto un tentativo estremo (più dovuto alla frustrazione che a una scelta mirata) modificando la descrizione del descriptor Cabal sostituendo la parola “at” (che proprio non gli piaceva) con un semplice “here”. Non so perchè e non mi interessa, ma il “fix” funziona alla grande:

Setting up libghc6-pcre-light-dev (0.3.1-3ubuntu1) ...
Reading package info from "/usr/lib/haskell-packages/ghc6/lib/pcre-light-0.3.1/installed-pkg-config" ... done.
building GHCi library /usr/lib/haskell-packages/ghc6/lib/pcre-light-0.3.1/ghc-6.8.2/HSpcre-light-0.3.1.o... done.
Saving old package config file... done.
Writing new package config file... done.

Anche il maintainer del pacchetto si è fatto una bella risata e ha deciso che il “fix” gli piace:

 haskell-pcre-light (0.3.1-5) unstable; urgency=low
.
* Apply a workaround for the misformatted installed-pkg-config file which
results an installation failure on some platforms (e.g. mips).  Thanks to
Luca Falavigna for the patch.  Closes: #482079
* Bump Standarts-Version to 3.8.0.

Appuntamento alla prossima stranezza

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Sono appena rientrato dalla calda Bologna, dopo aver trascorso un’interessante giornata con Leo Iannacone, Andrea Gasparini e Filippo Giunchedi. Ne abbiamo approfittato per parlare di informatica in generale, sviluppo di Debian e Ubuntu e un po’ di sano cazzeggio (niente ch3ch2oh per questa volta). Ghiotta occasione per fare un piccolo keysign party, considerando che Filippo è sviluppatore Debian

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Gli aggiornamenti che trovate nei repository -updates, prima di essere tali, passano un periodo di verifica nei repository -proposed, un’area di contenimento non abilitata di default (vista la natura rivolta al testing dei pacchetti contenuti). Siccome gran parte di questi pacchetti contiene fix per problemi di uso comune, perchè non abilitarli e provare in prima persona la bontà degli aggiornamenti proposti?

Ubuntu QA ha preparato una pagina wiki in cui sono contenute tutte le informazioni necessarie per poter abilitare i repository -proposed in tutta tranquillità e sicurezza. Discorso interessante è la sezione relativa al pinning, in questo modo gli aggiornamenti verranno segnalati ma non installati di default, lo saranno solo dopo specifica richiesta dell’utente, garantendo la totale autonomia nella scelta di quali aggiornamenti installare.

Ma per qual motivo un utente comune dovrebbe abilitare questi repository? Spesso un problema che affligge molti utenti è già stato segnalato e risolto con un aggiornamento nei repository -proposed. Avendo la disponibilità materiale di un aggiornamento, si risolve concretamente il problema e si aiuta gli sviluppatori nella migrazione degli aggiornamenti nei repository -updates commentando il bug associato ad un determinato aggiornamento. Anche se non sono ancora supportati ufficialmente, nella stragrande maggioranza dei casi l’aggiornamento è di ottima fattura (anche perchè è necessaria una specifica approvazione da parte di un gruppo di sviluppatori preposti, di cui faccio parte), quindi il rischio di regressioni è davvero minimo.

Happy -proposed!

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Seguendo il consiglio di Giacomo Catenazzi (”gli sviluppatori dovrebbero usare sempre la unstable, cosa vuoi che sia qualche –force-all ogni tanto”), ho effettuato l’aggiornamento ad Intrepid. Per ora, solo un problema con debconf (assertion failed imputabile ad un altro pacchetto, dovrebbe essere stato risolto con gli aggiornamenti della notte) e qualche downgrade per avere una Intrepid “pulita”. Vedremo gli sviluppi

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Ora i MOTU hanno la possibilità di effettuare i give-back in autonomia:

Ora vediamo che altri danni possiamo provocare

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Come annunciato da Colin Watson, sono iniziati i lavori per Intrepid Ibex. Dopo l’aggiornamento della toolchain e i primi autosync con Debian, stanno arrivando i primi merge e le richieste di sync.

Nella giornata odierna, ho realizzato alcuni merge e richiesto una decina di sync, i quali saranno processati, salvo impedimenti, nei prossimi giorni.

Con l’apertura del ciclo di sviluppo, vedrò di ricominciare la collaborazione col Gruppo Promozione per la pubblicazione dei pacchetti realizzati dalla comunità italiana all’interno della newsletter.

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Ok, Hardy è stata rilasciata, eviterò di dilungarmi su di un argomento che verrà trattato in tutte le salse nel giro di poche ore. E’ ora il tempo delle Classifiche!

TOP UPLOADERS
1 Jonathan Riddell (831 packages)
2 Sebastien Bacher (606 packages)
3 Matthias Klose (563 packages)
4 Luke Yelavich (404 packages)
5 Martin Pitt (362 packages)
6 Michael Bienia (348 packages)
7 Michael Vogt (340 packages)
8 Timo Aaltonen (303 packages)
9 Colin Watson (276 packages)
10 Steve Kowalik (253 packages)
11 Stephan Hermann (245 packages)
12 Mario Limonciello (240 packages)
13 Luca Falavigna (240 packages)
14 Steve Langasek (213 packages)
15 Scott Kitterman (179 packages)

TOP ITALIAN UPLOADERS
12 Luca Falavigna (240 packages)
22 Cesare Tirabassi (115 packages)
31 Andrea Colangelo (78 packages)
41 Michele Angrisano (61 packages)
60 Mario Bonino (35 packages)
61 Fabio M. Di Nitto (35 packages)
65 Emanuele Gentili (30 packages)
84 Andrea Gasparini (18 packages)
92 Andrea Veri (15 packages)
110 Matthew East (10 packages)
134 Daniel Schwitzgebel (6 packages)
140 Alberto Milone (tseliot) (5 packages)
165 Salvatore Palma (4 packages)
218 Maurizio Moriconi (2 packages)
234 Paolo Naldini (2 packages)
235 Naldini Paolo (2 packages)
(Paolo “Hattory” Naldini ha evidenti crisi di identità )

Che dire, ottimi piazzamenti, decisamente migliorati rispetto alla scorsa edizione

Popularity: 2% [?]

Puoi visualizzare il post originale qui.