Qualche giorno fa ho effettuato l’upload di ubuntu-it-menu, purtroppo non ci siamo accorti in tempo di un problema di licenza abbastanza grave che ne impediva la pubblicazione. Gli archive-admin sono stati gentili nell’approvare il pacchetto ugualmente, ma dietro promessa di risolvere il tutto in tempi rapidi.

Così è stato, Volans ha prontamente corretto l’estensione, Alexander ha dato l’ACK e io ho provveduto a caricare la nuova versione negli archivi. Ora sembra tutto OK, fino al prossimo bug

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Lo sviluppo di Ubuntu non finirà mai di stupirmi. Ecco ecco le ultime voci di corridoio.

Chi vuol essere archive-admin?
Prendendo in prestito il nome di un popolare quiz televisivo, ecco cosa dovrebbe cambiare a breve.

Nell’ambito della specifica Soyuz Community Admin, vi sono interessanti prospettive per l’assegnazione di compiti da archive-admin anche a membri della comunità MOTU (e quindi non solo a dipendenti di Canonical). La creazione di un ipotetico team motu-archive (come indicato nel bug #207680) permetterebbe, tra le altre cose, la possibilità di gestire in autonomia i sync, procedura di per sè non complessa, ma che richiedede l’intervento di un archive-admin per poter essere portata a termine.

Give-back o non give-back, questo è il problema
Un’altra interessante possibilità che potrebbe essere disponibile a una più vasta cerchia di sviluppatori è la possibilità di gestire in autonomia singoli give-back di pacchetti, nel caso in cui la compilazione non fosse riuscita per difetti temporanei o di varia natura. Finora questo era di competenza esclusiva dei buildd-admin, ma dare la possibilità a tutti gli sviluppatori di poterlo fare senza interventi di terze persone velocizzerebbe notevolmente il processo, senza rischi per l’integrità della distribuzione.

Upload in stile Debian Maintainer
Debian ha recentemente approvato e implementato la risoluzione Endorse the concept of Debian Maintainers, nella quale viene data la possibilità a singoli maintainer che non hanno ancora la qualifica di Debian Developer di caricare i propri pacchetti senza l’ausilio di uno sponsor. Anche in Soyuz è prevista una funzionalità di questo tipo nel bug #134456, per mezzo del quale chi non ha ancora i permessi di upload può comunque caricare i propri pacchetti in autonomia. Ovviamente rimane da definire chi e come assegnare i privilegi di upload, ma è una novità interessante e degna di nota.

Altre novità
Le novità citate non sono le uniche e forse ne arriveranno altre (la possibilità da parte di motu-sru di gestire il processo degli aggiornamenti in completa autonomia non sarebbe mal pensata). Rimane il fatto che quanto qui indicato è ancora un work in progress, ma dare più responsabilità a membri della comunità è un importante riconoscimento da parte di Canonical del lavoro svolto

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Steve Langasek, release manager di Ubuntu, ha annunciato l’ingresso nell’ultima fase dello sviluppo di Hardy, il Final Freeze, in cui tutti gli upload dovranno essere rivolti alla risoluzione di bug importanti per il rilascio finale, previsto per giovedì 24 aprile 2008.

Come preannunciato da Stefan Potyra qualche giorno fa, anche gli upload per universe e multiverse (a differenza di quanto avvenuto nelle release precedenti) dovranno essere approvati dai membri di motu-release o un loro delegato.

Milo, questo significa che anche in Hardy non avrai la traduzione di firestarter. Volevo inserirla in un altro upload, ma siamo arrivati un po’ lunghi

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Questa mattina ho effettuato l’upload in NEW di ubuntu-it-menu, l’estensione realizzata da Volans, la quale consente la navigazione rapida di tutte le risorse della comunità italiana di Ubuntu e di alcune risorse della comunità internazionale.

Ora la palla passa agli archive-admin per l’approvazione, se tutto va bene entro qualche giorno sarà disponibile nei repository di Hardy. Un ringraziamento ad Alexander Sack per i consigli preziosi.

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

… ma caricare robaccia su Soyuz è stata la cosa più avventata che abbia mai visto!

John, ringrazia la NEW queue e prega che non ti revochino i permessi di upload

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Uno degli obiettivi che mi ero posto per il rilascio di Hardy era risolvere un problema che si trascinava sin da Edgy: l’incompatibilità tra dietlibc e il meccanismo di protezione dello stack ProPolice, introdotto con gcc 4.1.

In Edgy si era preferito compilare dietlibc con -fno-stack-protector per ovviare a problemi di compilazione, ma non ci si è accorti che questa soluzione ha causato più danni che benefici. Tutti i programmi compilati con la versione modificata di dietlibc subivano crash all’avvio perchè compilati con ProPolice, mentre dietlibc non lo era.

Le strade possibili erano due: ricompilare i vari pacchetti senza supporto a ProPolice oppure tentare di riabilitarne il supporto in dietlibc. La prima ipotesi avrebbe comportato la modifica di quindici pacchetti, non difficile da realizzare ma complicato da gestire in futuro (merge, verifiche, ecc…). La seconda via sarebbe stata meno brigosa, ma sicuramente più tosta da realizzare, considerando la mia scarsa conoscenza del pacchetto.

Ho scelto la seconda ipotesi, la patch risultante è questa. Le modifiche che ho fatto sono le seguenti:

• Abilitare il supporto per lo stack protector (#define WANT_SSP)
• Definire __stack_chk_fail_local come alias di __stack_chk_fail (previene errore di compilazione)
• Abilitare l’uso di -fno-stack-protector per SPARC e PowerPC (previene errore di compilazione)

Ho poi caricato i vari rebuild dei pacchetti che compilano con il supporto dietlibc in modo da utilizzare la nuova versione, finalmente a posto. La specifica che ho creato a suo tempo è risolta

Grazie a Pietro, Paolo e Stefan per il testing fornito su PowerPC, amd64 e i386 rispettivamente.

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

La marijuana e derivati non c’entrano, mi riferisco alla queue Unapproved in Launchpad.

La queue Unapproved raccoglie tutti quei pacchetti in attesa di approvazione di un archive-admin (tra i quali gli SRU in attesa di approvazione) e, fino a ieri, essa era visibile solo agli archive administrator. Essendo membro di motu-sru (il team che si occupa di approvare le richieste di aggiornamento dei pacchetti in Universe), per me era una limitazione grave dato che non vi era la certezza che un upload in -proposed fosse già stato effettuato in precedenza.

Con la risoluzione del bug #181297, la queue è ora visibile a tutti:

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Nell’ambito della Ubuntu Developer Week, ieri sera ho tenuto su #ubuntu-classroom la mia sessione per quanto riguarda la tematica degli aggiornamenti di Ubuntu (Stable Release Updates o SRU). William Grant ha concluso parlando dell’altro tipo di aggiornamenti: i security update.

Per chi fosse interessato, qui c’è il transcript della sessione.

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Mark Shuttleworth ha annunciato il nome in codice di Ubuntu 8.10: Intrepid Ibex, il cui ciclo di sviluppo comincerà ad aprile per terminare nell’autunno del 2008. Nell’annuncio si possono leggere gli obiettivi della nuova distribuzione, uno su tutti il pieno supporto al networking.

E ora, rituffiamoci nello sviluppo di Hardy

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

In parallelo alla Ubuntu Open Week, la quale si svolge la settimana che segue il rilascio di ogni versione stabile di Ubuntu, Daniel Holbach ha annunciato la prima edizione di Ubuntu Developer Week, una serie di lezioni e tutorial in IRC in cui trattare tematiche legate allo sviluppo di Ubuntu e Debian. L’evento si svolgerà su #ubuntu-classroom da lunedì 18 febbraio a venerdì 22 febbraio.

• Home page e scaletta
• Breve sommario delle sessioni

Per quanto mi riguarda, sarò relatore (con William Grant) per quanto riguarda le tematiche relative agli SRU e agli aggiornamenti di sicurezza il giorno mercoledì 20 febbraio, ore 21 italiane.

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

In parallelo alla Ubuntu Open Week, la quale si svolge la settimana che segue il rilascio di ogni versione stabile di Ubuntu, Daniel Holbach ha annunciato la prima edizione di Ubuntu Developer Week, una serie di lezioni e tutorial in IRC in cui trattare tematiche legate allo sviluppo di Ubuntu e Debian. L’evento si svolgerà su #ubuntu-classroom da lunedì 18 febbraio a venerdì 22 febbraio.

• Home page e scaletta
• Breve sommario delle sessioni

Per quanto mi riguarda, sarò relatore (con William Grant) per quanto riguarda le tematiche relative agli SRU e agli aggiornamenti di sicurezza il giorno mercoledì 20 febbraio, ore 21 italiane.

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

… e a quanto pare piacciono anche a due utenti del forum di Ubuntu-it.

Nei giorni scorsi ho effettuato l’upload di due proposte di aggiornamento (SRU), openmpi e ncpfs, i quali hanno risolto i bug #152273 e #140464. Ho scoperto casualmente che due utenti sul forum avevano riscontrato gli stessi problemi:

• MPICC non compila file .c
• Novell Client per Ubuntu

Con gli aggiornamenti, il loro problema si è risolto. Good job

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Gli aggiornamenti di Ubuntu (in gergo chiamati Stable Release Update o SRU) necessitano di una procedura piuttosto laboriosa prima di poter essere distribuiti al grande pubblico. Escludendo gli aggiornamenti di sicurezza (i quali sono soggetti a diversa procedura), in passato si è riscontrata una certa titubanza nello sponsorizzare questo tipo di upload, vuoi per la poca familiarità con il processo, vuoi per la difficoltà di verificare la bontà della patch introdotta.

Negli ultimi giorni si è accesa una discussione su Planet GNOME sulla reale utilità degli aggiornamenti e sui motivi per i quali le bugfix-release di GNOME non siano considerate come tali. Sébastien Bacher, insieme ad altri archive-administrators, ha deciso di autorizzare tali rilasci usufruendo di particolari eccezioni (analogamente a quanto accade per questi pacchetti), in questo modo verrà risolto il problema delle segnalazioni di bug già risolti da GNOME ma che ancora affliggono le release stabili di Ubuntu, le quali costringono gli sviluppatori a svolgere attività di pulizia noiose e indesiderate.

Oltre a questo, Martin Pitt ha chiarito che gli aggiornamenti possono ricomprendere qualsiasi bug, a patto che la patch non provochi problemi di altra natura e che non coinvolga infrastrutture delicate come il kernel o il server grafico (per quei pacchetti, il requisito dell’importanza è ancora in vigore).

Per quanto riguarda gli aggiornamenti della componente Universe, il sottoscritto è responsabile dell’approvazione, della sponsorizzazione e della verifica degli aggiornamenti, in questo modo mi è possibile seguire tutta la trafila e velocizzare il processo di rilascio di un aggiornamento. Quando vedete comparire l’iconcina degli aggiornamenti, in parte è merito mio

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

In questi primi giorni dell’anno, ho dedicato parte del mio tempo per concentrarmi su un paio di aspetti trascurati nello sviluppo di Ubuntu. Eccone un breve riassunto:

Bug ‘Fix Committed’
Ubuntu ha un folto numero di bug marcati come ‘Fix Committed‘ ma che sono in realtà già risolti. In questi giorni ne ho chiusi una trentina, nell’immediato futuro vedrò di processarne altri per ridurre l’elenco ai minimi termini, approfittando anche del periodo di calma che precede il rilascio di Alpha 3.

FTBFS legati a /bin/dash
Approfittando dell’eccellente attività svolta da Lucas Nussbaum, ho iniziato a caricare qualche pacchetto negli archivi per risolvere gli errori di compilazione derivanti dalla transizione a /bin/dash come shell di default (la transizione è avvenuta in Edgy e ancora siamo qui a parlarne…).
Questa attività richiede il coordinamento con i maintainer Debian per mezzo del BTS, con la speranza che le modifiche segnalate vengano in seguito introdotte per ridurre le differenze tra le due distribuzioni.
Se qualcuno fosse interessato, sarò felice di sponsorizzare gli upload

Popularity: 2% [?]

Puoi visualizzare il post originale qui.

Scott James Remnant, con una lunga mail su ubuntu-devel, ha proposto un cambiamento radicale all’attuale struttura dei repository e dei permessi di upload in Ubuntu. Ecco un riassunto:

Niente più universe e multiverse
La proposta prevede di far confluire i pacchetti attualmente distribuiti in universe e multiverse rispettivamente in main e restricted. La motivazione di questa scelta è legata al supporto: tutti i pacchetti in main dovrebbero ricevere supporto ufficiale da Canonical ma in realtà non è così (la maggior parte dei pacchetti di Xubuntu, per esempio, non sono supportati pur essendo in main). Quindi, la principale differenziazione tra i due componenti viene meno.
Abbandonando la distinzione tra main e universe, alcune problematiche alla base dell’ogre model (un pacchetto in main non può dipendere da uno in universe) verrebbero meno, così come la necessità di predisporre i MIR (Main Inclusion Report).

I seed
La gestione dei pacchetti sarebbe integralmente basata sui seed, il potente sistema di gestione dei pacchetti implementato in dak. Il nuovo metodo prevede di creare altri seed in aggiunta a quelli già presenti raggruppandoli per aree di interesse (per esempio i pacchetti di Kubuntu, di Edubuntu o Xubuntu), i quali potranno avere supporto e aggiornamenti di sicurezza su base differenziata a seconda dell’importanza e del grado di diffusione tra gli utenti.

Diritti di upload
Anche la gestione dei permessi di upload subirà profondi mutamenti. Attualmente esistono due categorie di sviluppatori, ubuntu-dev e ubuntu-core-dev. I primi hanno facoltà di upload solo per i pacchetti inseriti in universe e multiverse, gli ultimi anche in main e restricted. Con il nuovo metodo, i permessi di upload saranno gestiti in questo modo:

I membri di ubuntu-core-dev avranno permessi di upload su tutto il parco software (come tuttora accade), mentre il discorso cambierà per gli appartenenti a ubuntu-dev, i quali avranno diritti di upload diretto solo per i pacchetti non presenti in alcun seed. Per i pacchetti inseriti nei seed, verranno costituiti specifici gruppi con privilegi di upload che saranno incaricati di gestire i pacchetti di loro competenza, in questo modo si verranno a creare dei gruppi di lavoro veri e propri con con competenze specifiche, analogamente a quanto accade in Debian.

Alcune considerazioni
L’idea proposta ha numerosi vantaggi (semplificazione delle procedure di gestione dell’archivio, maggiore cura e focalizzazione su aree di interesse, maggior controllo sull’operato del singolo sviluppatore), ma anche diversi svantaggi (riscrittura dell’intero sistema di management dei pacchetti in Soyuz, mancanza di un sistema centralizzato di visualizzazione dei seed, attività di modifica di dpkg/apt per l’implementazione delle nuove funzionalità).
Il discorso non è ancora ben definito siccome è richiesto parecchio lavoro (e sicuramente sarà preso in considerazione solo da Hardy + 1), ma i pareri sono favorevoli e qualche cambiamento sarà sicuramente preso in considerazione.

Popularity: 2% [?]

Puoi visualizzare il post originale qui.