Online sprints, or how to revive a L10N team

The Italian L10N team has not been very active nor growing in recent years. In particular, we pretty much failed at attracting new members in our team, with the result that untranslated files are piling up and manpower is scarce.

Following a suggestion of our uber-active Francesca,  we decided to try a new move to invert the trend: organizing brief weekly online sprints open to everybody, where graybeard translators will help newcomers getting to grips on Debian L10N infrastructure while collaboratively working on yet-untranslated targets.

Last week, we tried our first and very introductory sprint, with a preliminary meeting on IRC to give instructions and setup ad-hoc pads. As a result, we ended with linux-2.6 po-debconf and a web-page completely translated and proofread by almost fifteen people in just a couple a hours. The key point however is that the majority of participants were fresh L10N-newbies, which we hope will join us permanently very soon after this first contact.

Encouraged by the initial positive result, we already announced our next sprint for Thursday 11th, which will be focused on package descriptions translation (preceded by a crash course on DDTSS, its related web interface).

We hope that even more users will join us this time, and encourage other “stalled” translation teams in experimenting a similar approach to revive activity and encourage participation.

Annunci
Online sprints, or how to revive a L10N team

Resoconto della Debian/Ubuntu Community Conference 2010, Perugia

Nei giorni 17/18/19 settembre si è svolta a Perugia la quinta edizione della Italian Debian Community Conference, che ha visto la partecipazione di un buon numero di sviluppatori e utenti.
Per la prima volta l’evento è stato organizzato insieme alla comunità italiana Ubuntu, dando vita ad un nuovo tipo di conferenza congiunta mirata ad incentivare il lavoro comune, enfatizzando i molti tratti condivisi dai due progetti.

Dopo una prima serata informale, trascorsa a discutere dei progetti in corso cenando in compagnia, la conferenza ha ufficialmente preso il via sabato, presso l’università di Perugia, con una serie di talk tecnici volti a incoraggiare la partecipazione di nuovi contributori sia nel campo dello sviluppo che in quelli della traduzione, documentazione e promozione. L’evento è stato anche un’opportunità per celebrare il Software Freedom Day, con la partecipazione di alcune scuole della zona e del FSUG Italia.

DUCC-IT '10 Group Photo

All’evento erano presenti anche membri dei team Debian Women e Ubuntu Women (il cui obiettivo principale consiste nel promuovere la presenza femminile nei due progetti) che hanno dato vita ad un dibattito sulla presenza delle donne nel panorama italiano del software libero, presso i locali dell’hacklab perugino. La discussione ha toccato diverse tematiche, tra cui la grande differenza di numero tra contributori di sesso maschile e femminile, i motivi alla base di questa sproporzione e le iniziative da intraprendere per invertire questa tendenza.

Questo nuovo tipo di collaborazione tra le due comunità si è rivelato vincente sotto molti aspetti, permettendo di condividere nuove conoscenze e di migliorare i progetti comuni. L’auspicio conclusivo dei partecipanti è stato quello di poter ripetere in futuro questo tipo di collaborazioni, estendendolo anche ad altri campi.
In particolare, è stata prevista nei primi mesi del 2010 l’organizzazione di altri eventi comuni, come un translation party ed un nuovo meeting delle comunità.

Inoltre, sarà presto disponibile un resoconto più dettagliato dell’evento con foto, commenti, registrazioni delle sessioni e relative slide.
Ringraziamo il dipartimento di matematica dell’università di Perugia, l’hacklab Projects On Island, FSUG Italia, la communità Ubuntu-it e tutti gli individui che hanno collaborato alla realizzazione di questo evento.

Resoconto della Debian/Ubuntu Community Conference 2010, Perugia

Report from the Debian/Ubuntu Community Conference, ITA 2010

From the 17th to the 19th of September in Perugia, Italy, it took place the 5th edition of the Italian Debian Community Conference, which has been attended by many contributors and users.

For the first time, the event has been organized in collaboration with the Italian Ubuntu community, as to create a new joint conference in order to foster shared contributions and emphasizing the large common ground of our projects. This new experimental kind of mini-conference was then labeled DUCC-IT, to reflect both the local profile and the mutual collaboration.

After the initial social night, spent discussing of several ongoing free software efforts and having dinner all together, the conference official opening started on Saturday, temporarily housed at University of Perugia, with a series of talks and hands-on session aimed at recruiting new contributors to work on development, translations, documentation writing and marketing. It has been a good opportunity to celebrate the Software Freedom Day too, in collaboration with FSUG Italia and the participation of some local schools.

DUCC-IT '10 Group Photo

The event been also attended by some members of the Debian Women and Ubuntu Women teams (whose goal is to promote women participation in both projects), who organized a round-table debate taking the Italian panorama as a study case. The discussion embraced different topics, ranging from the wide difference in numbers, to the deep causes of this phenomenon and how to improve the situation. With the help of the hacklab staff (hosting the debate), an audio/video streaming has been made available in real-time, and many remote participants joined us with comments and questions.

This new kind of collaboration between our communities was found to be really positive and more events has already been drafted for the next year, including a translation sprint and a contributors meeting.

We encourage worldwide local communities to try and engage in a similar experiment: organizing and joining a DUCC event will be pure fun.

A detailed report of the conference will be soon available, completed by photos, participants’ comments, video records and slides for the talks.
We’d really like to thank the Math Department of University of Perugia, the Projectz On Island hacklab, FSUG Italia, the Ubuntu-it community and everyone who contribute to this event.

Report from the Debian/Ubuntu Community Conference, ITA 2010

Sending mail through a SSL-only relay server with ssmtp

I sometime feel the need of sending mail directly from my terminal (eg. with mail or reportbug) without having a complete mail-server on my laptop, which is often offline or NATted. For this, I’ve started to use ssmtp, a simple MTA which only delivers local mails to a more powerful remote SMTP-server. I’ve configured it to only communicate over an encrypted TLS connection to well-known port 465, to avoid man-in-the-middle sniffers and firewalls filtering outgoing port 25. This is my configuration (can be tuned via /etc/ssmtp/smtp.conf on Debian-like systems):

root=myuser
mailhub=mail.example.org:465
rewriteDomain=example.org
hostname=myhost.example.org
UseTLS=yes
UseSTARTTLS=no
AuthUser=myuser@example.org
AuthPass=XXXXX
FromLineOverride=YES

Of course, you need an external mail server configured to relay your mail and accepting TLS connections. For this purpose, you could also use a free mail service, like GMail.

Sending mail through a SSL-only relay server with ssmtp

Uzbl in Debian

After some delay, uzbl is now available in Debian (testing and unstable). Uzbl is a webkit based browser which aims to adhere to the Unix philosophy of having programs that do one thing and do it well; as such, it comes with a main binary (uzbl-core), acting as the real web-renderer, which is controllable by third-parties via standard fifo’s and sockets. The package also bundle some external helper scripts for daily web-surfing (ie. handling history, bookmarks, cookies, etc.) and a ready-to-user wrapper (uzbl-browser) to help setting up the environment, using the default config.
As a standalone browser, it may look quite similar to vimperator (default key-bindings and interface are strongly vim-like), but overall it offers a more powerful and completely reconfigurable user-interface, can be fully scripted and hooked with self-made helpers and is even embeddable in other applications (eg. Emacs). Nonetheless, it brings all the power of a fully fledged webkit renderer.

You may find it particularly useful when working within a tiling window manager (like awesome or xmonad), or used as a full-screen remote monitor, easily controllable via socket (you should really try socat with it!) or plain-text fifo (for a bunch of stats, as easy as a `echo "uri italiaora.org" > /tmp/uzbl_fifo_your-instance`)

Uzbl in Debian

Wireshark IPv6 DNS support (via libadns)

In the end, I get really bored by wireshark loudly complaining about my default IPv6 nameserver and its inability to use that annoyed me, so finally last week I’ve found some time to fix #384372 directly in libadns.
Wireshark (and all other applications using libadns as their asynchronous resolver) would now be able to query IPv6 capable nameservers and handle AAAA as well as ip6.arpa PTR queries (Niels Möller already worked it).
Here’s below a live-action screenshot from my IPv6 tunneled worstation (and thanks SixXS for it):

Sid packages are available for testing on both i386 and amd64, so go and try it! (patch and git repository available too).
I hope it will get merged upstream and in unstable soon.

P.S. unfortunately the same day I finished this patch, wireshark upstream decided to switch to c-ares library, which seems to suffer of a similar/weirder issue. Previous versions of wireshark (< 1.2.0) will work like a charm with adns (beware of several CVE recently fixed), and newest ones can be safely built with –without-c-ares (falling back to libadns). I’ll probably spend some time on it too, soon…

Wireshark IPv6 DNS support (via libadns)

You got it all… wrong

A volte capita, qualche incomprensione o qualche passaggio perso nella traduzione in lingua. Il problema è quando inizia a venire ripresa una notizia sbagliata, o senza le condizioni al contorno, e ben presto si trasforma in tutt’altra cosa. Intervengo quindi, mio malgrado a gamba tesa, sul post di Pollycoke (che è già stato ripreso almeno qui e qui, ma ho paura si spargerà presto oltre), metto per un momento il mio cappello da Debian Developer e cerco di chiarire ciò che non è stato compreso, condendo il tutto con qualche buon link.

Intanto, la discussione non riguarda per nulla i firmware proprietari o driver o cose simili nella loro definizione classica (so che stan già tutti pensando ai driver Nvidia o ai firmware delle schede wifi Intel), quelli non ho la più pallida idea di come sian stati tirati in ballo perchè non hanno a che fare con questa votazione.
Poi, non non è nulla di «clamoroso» perchè scelte simili eran già state effettuate per le vecchie release (per diversi firmware inclusi nel kernel, e ora altri ne sono stati aggiunti upstream). Inoltre, l’ex-segretario Manoj non si è dimesso per la scelta finale (infatti ha dato le dimissioni prima della fine della votazione e prima  che si conoscesse l’esito) ma per alcuni malumori su come era stata impostata la votazione.
Infine, l’esito della votazione è, citando testualmente: «Daremo priorità al rilascio imminente di Lenny piuttosto che sinstemare ogni singolo tassello; per questa ragione la rimozione dei firmware senza sorgente sarà un processo al meglio dei nostri sforzi, e in Debian Lenny saran distribuiti quei firmware per cui ci è legalmente possibile farlo E che sono distribuiti dall’upstream sotto una licenza che rispetti le DFSG.» (Proposal E, punto 4, traduzione e enfasi mie)
Fin qui, solo le necessarie correzioni.

Scendendo nei dettagli, l’oggetto della discussione sono quei pezzi di firmware distruibiti dall’upstream (Linus e kernel.org, nello specifico caso) sotto una licenza che rispetti le DFSG (GPLv2 nel caso del kernel Linux, da cui il titolo di questo risultato) che sono attualmente inseriti come buffer di codice esadecimale all’interno dei sorgenti C del kernel (comunemente detti blob). Ci sono vari bug-report aperti in proposito, nonchè una pagina del wiki un po’ più discorsiva. In estrema sintesi, questi pezzi di binari sono dati da caricare nei dispositivi per l’inizializzazione affinché i componenti funzionino correttamente e non è semplicissimo definire quale ne debba essere l’effettivo formato sorgente preferito.
Secondo molti kernel hacker la questione non è troppo poblematica, tuttavia altri sviluppatori (upstream e non) stanno lavorando affinchè si possa non averli direttamente distribuiti dentro al kernel, senza arrecare troppi problemi agli utenti. Il progetto GNU ha un’iniziativa mirata alla rimozione completa di questi firmware. Debian si trova a metà, tra l’incudine e il martello, tra gli utenti e l’upstream (e vincolata dalle DFSG) in posizione assai più delicata.

L’esito della votazione rispetta le DFSG e il Contratto Sociale, perché tiene conto del nostro impegno verso gli utenti E il software libero e perché (legalmente) il firmware distribuito in forma esadecimale (blob) nei sorgenti di Linux ricade a tutti gli effetti sotto la licenza stessa del prodotto distribuito (per il kernel GPLv2 ove non altrimenti specificato).

In conclusione, con questa votazione il progetto Debian ha stabilito che per Lenny rispetterà le scelte dell’upstream (del kernel) di definire tali blob come effettivamente coperti da GPL (e quindi nella loro forma di sorgente preferito), pur non ritenendo ottimale la situazione attuale, dovendo dare priorità al prossimo rilascio stabile e lasciando a metà la soluzione di questa problematica (rimettendola agli sforzi dei singoli o a una futura decisione).

Aggiungerei solo che questo post è frutto di quanto è di mia conoscenza, senza addentrarmi troppo nelle discussioni più sottili o nei tecnicismi e cercando di restare oggettivo. Posso chiaramente avero perso alcuni punti interessanti/non-banali per strada o commesso qualche imprecisione, per cui i commenti costruttivi/non-frivoli sono benvenuti.

P.S. sì, cit. The Hives 🙂

You got it all… wrong