blog/archives/2010/01zack's home pagehttp://upsilon.cc/~zack/blog/archives/2010/01/zack's home pageikiwiki2010-01-31T09:59:59ZRC bugs of the week - issue 19http://upsilon.cc/~zack/blog/posts/2010/01/RC_bugs_of_the_week_-_issue_19/2010-01-31T09:59:59Z2010-01-31T09:51:30Z
<h1><acronym title=
"Release Critical Bugs of the Week">RCBW</acronym> - #19</h1>
<p>Back with the "ordinary track" of RCBW, here is this week
squashes by yours truly:</p>
<ul>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/546492">Debian bug #546492</a></span> -
djvulibre - provided patch implementing
<code>get-orig-source</code> to strip non-free specification
docs</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/550394">Debian bug #550394</a></span> -
courier-imap - not affected/responsible by the imap-server virtual
package mess</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/550397">Debian bug #550397</a></span> -
kolab-cyrus-imapd - not affected/responsible by the imap-server
virtual package mess</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/550380">Debian bug #550380</a></span> -
uw-imapd - provides <em>and</em> conflicts with imap-server, fixing
file-overwrite errors</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/559698">Debian bug #559698</a></span> - rox
- drop useless build-dep on libxtrap-dev (which will be gone
soon)</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/559829">Debian bug #559829</a></span> -
synfig - disable vulnerable embedded libltdl, fix CVE</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/520557">Debian bug #520557</a></span> -
lemon - proper version tagging, already fixed</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/547726">Debian bug #547726</a></span> -
myspell-el-gr - forcibly orphan the package, "fix" maintainer
address</li>
</ul>
<p>The attentive reader have noticed that there is one more than
usual, the reason is the mighty <a href=
"http://wiki.debian.org/BSP2010/Moenchengladbach"><strong>BSP in
Mönchengladbach</strong></a>, which has powered all above squashes.
I've enjoyed the BSP a lot, my first in Mönchengladbach, which
won't be the last. I recommend checking it out at least once in the
future, even only for tasting Formorer's chili <img src=
"http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" /></p>
<p>The main highlight of the week is my personal award to the
<strong>best feedback ever from an NMU-ed maintainer</strong>, the
award <a href=
"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550380#54">goes
to Jonas</a>, kudos for your attitude.</p>
concorsi truccati ... e dajehttp://upsilon.cc/~zack/blog/posts/2010/01/concorsi_truccati_..._e_daje/2010-01-25T21:54:36Z2010-01-25T21:54:36Z
<h1>niente di nuovo sotto il sole</h1>
<p>Chi ha parlato con me di <strong>concorsi truccati</strong> che
impediscono ai "giovani ricercatori"™ di essere assunti in Italia
ha difficilmente trovato terreno fertile. La mia disciplina
(l'informatica scientifica) è relativamente nuova e quindi più
fortunata di discipline più antiche: le cosiddette baronie si
stanno si affermando, ma in buona parte d'Italia (e limitatamente
ai dipartimenti che ho avuto modo di conoscere) è ancora possibile
trovare concorsi da ricercatore in informatica che siano
specchiatamente meritocratici. Badate: non ho detto che sia la
norma, ma ... <em>«piuttosto che niente, è meglio
piuttosto»</em>.</p>
<p>Nel mio ambito di interesse dunque, il problema della assunzione
dei giovani è dominato più dalla <strong>scarsità di posti</strong>
che non dal malcostume dei concorsi truccati. A parità di
competenze scientifiche ed età, la Francia è in grado di assumere
<em>ogni anno</em> molti più ricercatori in informatica di quanto
non sappia fare l'Italia. Per questo è piuttosto comune imbattersi
in laboratori di ricerca francesi dove i ricercatori italiani sono
statisticamente sovra-rappresentati rispetto ad altre
nazionalità.</p>
<p>In altre discipline e/o in altri piani della gerarchia
accademica, le carte in gioco sono molto diverse. Riporto a questo
proposito la (yet another) <strong>horror story</strong>
dell'assunzione di 2 professori ordinari per trasferimento a Roma
Tre. Niente di nuovo, ma questa ha avuto immeritatamente poca
risonanza e la riporto con piacere.</p>
<p>Breve rassegna stampa:</p>
<ol>
<li>
<p><a href=
"http://www.ilsole24ore.com/art/SoleOnLine4/dossier/Italia/2009/commenti-sole-24-ore/11-dicembre-2009/universita-arsenico-vecchi-concorsi.shtml">
l'articolo iniziale</a> di Roberto Perotti sul Sole, che introduce
la vicenda.<br />
<small>(Per chi non lo conoscesse, Perotti è autore del bellissimo
libro <a href=
"http://www.ibs.it/code/9788806193607/perotti-roberto/universit-agrave-truccata.html">
<em>l'università truccata</em></a>, uno dei più belli ed
equilibrati testi che io abbia letto sulle "sventure"
dell'università italiana.)</small></p>
</li>
<li>
<p><a href=
"http://www.ilsole24ore.com/art/SoleOnLine4/dossier/Italia/2009/commenti-sole-24-ore/15-dicembre-2009/universita-riforma.shtml">
(i tentativi di) risposta</a> degli attori del concorso, sempre sul
Sole</p>
</li>
<li>
<p>infine, <a href=
"http://www.noisefromamerika.org/index.php/articles/Concorsi_manipolati%3A_il_caso_di_Roma_Tre">
l'analisi</a> di Michele Boldrin sui meriti scientifici dei
candidati in gioco per la cattedra di Economia Politica<br />
<small>(Shameless plug per i cater-fan: Boldrin è l'economista di
riferimento di <a href=
"http://caterpillar.blog.rai.it/">Caterpillar</a>.)</small></p>
</li>
</ol>
<p>I miei <strong>highlight</strong> sulla vicenda sono i
seguenti:</p>
<ul>
<li>
<p>In molti, ed io tra loro, ritengono non sia possibile stabilire
un unico strumento di valutazione <em>automatico</em> per
l'attività di ricerca (i.e. <a href=
"http://www.harzing.com/pop.htm">PoP</a> non è la soluzione). Ciò
nondimeno, le personalità scientifiche attive in specifici ambiti
possono facilmente smascherare i candidati impresentabili ad un
concorso, grazie semplicemente alla loro cultura su quali siano le
basi dati (motori di ricerca, indici di riviste, conferenze note,
...) scientificamente affidabili da consultare. Non è altrettanto
facile garantire che <q>vinca il migliore</q>, ma smascherare gli
impresentabili costituisce un contributo fondamentale a minimizzare
i danni per l'università che assume il vincitore del concorso (e
quindi per la collettività).</p>
</li>
<li>
<p>Uno dei punti (ricorrenti) di Perotti resta la chiave di
tutto:</p>
<blockquote>
<p>In qualsiasi paese moderno nessun esponente accademico si
sarebbe esposto in una vicenda così imbarazzante: la tradutio
manuale dei titoli, la clamorosa disparità di valore scientifico di
vincitori e sconfitti, le parentele, il cerchiobottismo politico.
Inoltre, rettore e preside, e l'intera università con loro,
avrebbero perso molto di più in immagine e prestigio di quanto
avrebbero guadagnato in altre dimensioni.</p>
<p>Perché questa totale indifferenza? Il motivo è sempre lo stesso:
nell'università italiana si procede solo per anzianità, nessuno
paga per le scelte sbagliate e nessuno viene premiato per operare
bene. Che io promuova un premio Nobel oppure l'amico o il parente,
il mio stipendio e la mia carica continuano esattamente come
prima.</p>
</blockquote>
</li>
</ul>
<p>In tale contesto di deresponsabilizzazione generale
<strong>nessuna isola felice può durare a lungo</strong>, <a href=
"http://mailserver.di.unipi.it/pipermail/grin/msg02608.html">le
avvisaglie</a> sono tristemente note.</p>
RC bugs of the week - issue 18http://upsilon.cc/~zack/blog/posts/2010/01/RC_bugs_of_the_week_-_issue_18/2010-01-22T11:34:03Z2010-01-22T11:34:03Z
<h1><acronym title=
"Release Critical Bugs of the Week">RCBW</acronym> - #18</h1>
<p>... and RCBW <a href=
"http://upsilon.cc/~zack/blog/posts/2010/01/RCBW_strike_-_BSP_in_Moenchengladbach/">is
back</a>! Here is this week squashes:</p>
<ul>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/544879">Debian bug #544879</a></span> -
clutter - resurrect -doc package, fix gtk-doc related FTBFS</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/504980">Debian bug #504980</a>, <a href=
"http://bugs.debian.org/560513">Debian bug #560513</a></span> -
cryptonit - add missing #include for gcc 4.4 (bonus point: misc QA
fixes)</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/504901">Debian bug #504901</a></span> -
dibbler - no longer valid gcc FTBFS</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/504869">Debian bug #504869</a></span> -
scim-bridge - closed (w maintainer) as unreproducible an already
fixed gcc 4.4 bug</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/505390">Debian bug #505390</a></span> -
traverso - add missing
<h1>include for gcc 4.4</h1>
</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/562846">Debian bug #562846</a></span> -
flim - drop Recommends on metamail (now gone)</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/526207">Debian bug #526207</a></span> -
jaula - closed as unreproducible a gcc 4.4 bug (recent flex adds
cstdio by itself)</li>
</ul>
<p>Most of the actually fixed missing include bugs above have
benefited from patches by Martin Michlmayr, thanks!</p>
<p>Also, this week squashing has benefited from a <strong>huge list
of bugs</strong> which Luk has given me, some of the not-yet-fixed
bugs there are a bit trickier than usual (e.g. missing
<code>#include</code> bugs which got intertwined over time with
<code>const char *</code> conversions bugs, which in turn require
some far reaching code changes due to the propagation of function
prototypes in unexpected code parts).</p>
<p>Since I'll be leaving tomorrow morning for the <a href=
"http://wiki.debian.org/BSP2010/Moenchengladbach"><strong>BSP in
Mönchengladbach</strong></a>, I'll have a bit of time there to dive
a bit more into the issues.</p>
<p>Actually, what I fear most now is buying train tickets from
Cologne to Moenchengladbach and back, since I'm totally unable to
pronounce the name of the latter city (my German sucks, actually
there is no such "my German" at all). Luckily, I've been told
they've wonderful ticket-selling machines in Cologne <img src=
"http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" /></p>
<p>See you <a href=
"http://wiki.debian.org/BSP2010/Moenchengladbach">there</a>, and
happy RC squashing!</p>
bolognesi brava gentehttp://upsilon.cc/~zack/blog/posts/2010/01/bolognesi_brava_gente/2010-01-20T09:42:36Z2010-01-20T09:41:37Z
<h1>Bolognesi brava gente ...</h1>
<p>... <a href=
"http://www.corriere.it/politica/10_gennaio_20/Marino-e-la-nomina-a-Bologna-saltata-per-le-primarie-gerevini_3f83b9b4-0593-11df-a1d7-00144f02aabe.shtml">
própri</a>.</p>
<p><small>("Proprio", ovvero "come no", in dialetto
Bolognese.)</small></p>
git flag of the day --color-wordshttp://upsilon.cc/~zack/blog/posts/2010/01/git_flag_of_the_day_--color-words/2010-01-18T12:49:03Z2010-01-18T12:49:03Z
<h1>the ultimate text diffing helper</h1>
<p>I use <a href="http://git-scm.com">Git</a> not only for code,
but also for text, my most common use case being co-authorship of
scientific <strong>papers typeset in LaTeX</strong>.</p>
<p>While <strong>reviewing other author changes</strong>, the usual
line-by-line diff is often annoying since:</p>
<ol>
<li>
<p>Paragraph re-formatting gets in the way (hello guys accustomed
to compulsory Vim's <code>gq</code> or Emacs' <code>M-q</code>): it
does not effect the final rendering, but it still hinders
peer-review of changes.</p>
</li>
<li>
<p>Even in the simplest case of a single word change on a single
line, it will take some time for your eyes to spot where, along the
line, the actual change is.</p>
</li>
</ol>
<p>Stuff like <a href=
"http://packages.debian.org/sid/wdiff">wdiff</a> does help, but
I've never looked at how to integrate it with Git, and I still find
it a pain in the eyes due to the fancy ASCII arts used to denote
additions and deletions (pain that I usually experience when
looking at the output of <code>debdiff</code>). There are nice
diffing GUIs or editor-integrated solutions out there, but what
I've always dreamed of is a plain old cmdline geekism.</p>
<p>Enter Git's <code>--color-words</code>, that can be passed to
both <code>show</code> and <code>diff</code> commands. My favorite
related <a href="http://git.or.cz/gitwiki/Aliases">Git aliases</a>
are as follows:</p>
<pre><code> [alias]
wdiff = diff --color-words
wshow = show --color-words
</code></pre>
<p>Here is a sample fancy output, yet very intuitive and
console-based, of <code>git show --color-words</code> (text in red
denotes deletions, text in green additions):</p>
<p><a href=
"http://upsilon.cc/~zack/blog/posts/2010/01/git_flag_of_the_day_--color-words/wshow.png">
<img src=
"http://upsilon.cc/~zack/blog/posts/2010/01/git_flag_of_the_day_--color-words/x300-wshow.png"
width="367" height="300" alt=
"sample output of git show --color-words (screenshot)" class=
"img" /></a></p>
<p>Maybe not new to you, but it has been
<strong>life-changing</strong> for me.</p>
Kuhn on Debian, Ubuntu, and the culture of freedomhttp://upsilon.cc/~zack/blog/posts/2010/01/kuhn_on_debian_ubuntu_and_the_culture_of_freedom/2010-01-17T10:23:27Z2010-01-16T16:46:17Z
<h1>The culture of freedom lies in the details</h1>
<p>Here is an <a href=
"http://ebb.org/bkuhn/blog/2010/01/14/ubuntu-debian.html">interesting
blog post</a> by <a href=
"https://en.wikipedia.org/wiki/Bradley%20Kuhn">Bradley Kuhn</a>
about Ubuntu, Debian, and (warning: my interpretation ahead) the
culture of freedom.</p>
<p>While reading it, I had kinda moment of truth, because just
yesterday I was musing with Mehdi and Lucas on the fact that Debian
is basically the only remaining distribution among the mainstream
ones (if that means something) that is <strong>free from the ground
up</strong>, including its infrastructure. We "just" seek hardware
via <a href="http://www.debian.org/donations">donations</a> and
then we run, thanks to the amazing work of <a href=
"http://wiki.debian.org/Teams/DSA">DSA</a>, our own <strong>free
infrastructure</strong> on top of it.</p>
<p>Let's cherish this value!</p>
<p><small>Thanks to <a href="http://www.dicosmo.org">Roberto Di
Cosmo</a> for the pointer to Bradley's post.</small></p>
<p><strong>Update</strong>: there's <a href=
"https://lists.ubuntu.com/archives/ubuntu-devel/2010-January/029976.html">
a thread</a> on the ubuntu-devel mailing list about Bradley's
post.</p>
RCBW strike - BSP in Moenchengladbachhttp://upsilon.cc/~zack/blog/posts/2010/01/RCBW_strike_-_BSP_in_Moenchengladbach/2010-01-16T14:20:05Z2010-01-16T13:46:02Z
<h1>RC squashing news</h1>
<p>In the last two weeks I didn't progress as usual with RC bug
squashing, even if I've some squashes to share:</p>
<ul>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/545235">Debian bug #545235</a>, <a href=
"http://bugs.debian.org/560502">Debian bug #560502</a></span> - k3d
- add missing #include for gcc 4.4 (patch from Ubuntu)</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/552791">Debian bug #552791</a></span> -
acorn-fdisk - fix debian/copyright (sponsored NMU for my NM
Thorsten Glaser)</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/527371">Debian bug #527371</a></span> -
qemu-kvm - remove extra stuff (fix FTBFS when built twice in a
row)</li>
</ul>
<p>The reason for my under-activity are that for a week I'd
relatively <strong>scarce network connectivity</strong>, which is a
badly needed good for RCBW. Then, this week, I got swamped by
various tasks at the university (including co-authoring a paper
with <a href="http://www.lucas-nussbaum.net/blog">Lucas</a>, more
on this (hopefully) in the future).</p>
<p>My residual RCBW time has been devoted to write a <a href=
"http://upsilon.cc/~zack/hacking/debian/rcbw/"><strong>page about
RCBW</strong></a> where I've tried to summarize my initial
<em>motivations</em> and the <em>main points</em> of the
initiative, which I consider established by the first 18 weeks of
activity. Starting from next week I'll be back with daily squashes.
In the week-end ... drum roll ... I'll be attending the <a href=
"http://wiki.debian.org/BSP2010/Moenchengladbach"><strong>BSP in
Mönchengladbach</strong></a>, hosted by <a href=
"http://www.credativ.de/">Credativ</a>; I'll personally be kindly
hosted by <a href="http://bzed.de/tags/debian/">bzed</a> which I
thank already for that and for the BSP organization.</p>
<p>See you there (!?)</p>
Preserving privacy with Google Docshttp://upsilon.cc/~zack/blog/posts/2010/01/Preserving_privacy_with_Google_Docs/2010-01-15T09:49:50Z2010-01-15T09:43:58Z
<h1>Eclectic paper: SEcure GOogle DOCumentS</h1>
<p>Two days from an <a href=
"http://googleblog.blogspot.com/2010/01/new-approach-to-china.html">
important Google announcement</a>, <strong>privacy
awareness</strong> is steadily increasing in the media. The old
mantra that "despotic governments might use your data in unexpected
way" sounds more real than last week, and <a href=
"http://www.imdb.com/title/tt0405094/">recent movies</a> ring
different bells in our heads.</p>
<p>That event has prodded me to (finally!) blog about <a href=
"http://upsilon.cc/~zack/blog/posts/2009/11/Enforcing_type-safe_linking_using_package_dependencies/">
yet another eclectic paper</a> of <a href=
"http://upsilon.cc/~zack/research/publications/">mine</a>, co-authored with my
old friend <a href=
"http://www.cs.unibo.it/~gdangelo/index-eng.html">Gabriele
D'Angelo</a>, and which I'm going to present at <a href=
"http://www.acm.org/conferences/sac/sac2010/">the forthcoming ACM
SAC conference</a>. The paper is titled <a href=
"http://upsilon.cc/~zack/research/publications/sac10-coclo.pdf"><strong>Content
Cloaking: Preserving Privacy with Google Docs and other Web
Applications</strong></a> and poses (again) a rather simple
question: why should you trust Google to faithfully store your
<strong><a href="http://docs.google.com">Google Docs</a>
data</strong>? What if roles in the recent Google-vs-China issue
were inverted?</p>
<p>The proposed solution (Content Cloaking) then simply implements
<strong>transparent encryption and decryption</strong> in the
payload which is sent back and forth between your browser and the
Docs backend. Trying to access your Docs data without a decryption
layer and the needed key will then just show garbage, for both
humans and Google harvesters. Of course you lose something, like
full text search which is performed server-side by Google, but at
least you're back in charge again: it is you who decides to which
extent trading-off your privacy with offered services.</p>
<p>A <strong>proof-of-concept implementation</strong> is provided
(and of course is free software!) as an extension for the Firefox
browser, but is now out of date wrt Firefox mainline and was not
really production ready anyhow (let's say it was
master-thesis-implementation-quality ...). Still we, the authors,
stand behind the idea even if we don't have the energy to maintain
a production-quality implementation.</p>
<p>So, <strong>Dear LazyWeb</strong>, If you are interested in the
topic and you've development cycles to spare, please <a href=
"mailto:zack@upsilon.cc">drop me a mail</a> and I'll be happy to
point you to all needed details to resurrect the implementation (or
create one from scratch, which should be pretty easy and quick if
you're familiar with extension development).</p>
RC bugs of the week - week 17http://upsilon.cc/~zack/blog/posts/2010/01/RC_bugs_of_the_week_-_week_17/2010-01-03T09:54:03Z2010-01-03T09:54:03Z
<h1><acronym title=
"Release Critical Bugs of the Week">RCBW</acronym> - #17</h1>
<p>Given that my "most blogged" Debian activity since last summer
has been RCBW, what else could be my first post of 2010 if not a
RCBW update? With further ado, here are <strong>this week
squashes</strong> by yours truly:</p>
<ul>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/559898">Debian bug #559898</a></span> -
flowcanvas - fixed in unstable, tag as needed</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/562503">Debian bug #562503</a></span> -
man-db - downgrading severity (RC-ness was in zlib, which is now
fixed)</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/541610">Debian bug #541610</a></span> -
docbook2odf - switch dep away from (now gone)
libxml-sablot-perl</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/528088">Debian bug #528088</a></span> -
ttf-aenigma - fonts are actually free, as detailed in
debian/copyright</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/544113">Debian bug #544113</a></span> -
tiger - remove dep on essential package (bonus: misc deps/debhelper
fixes)</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/561466">Debian bug #561466</a></span> -
ttf-beteckna - rebuild against fixed defoma (thanks Julien Cristau
who spotted a wrong fix of mine)</li>
<li><span class="bug strike"><a href=
"http://bugs.debian.org/561470">Debian bug #561470</a>, <a href=
"http://bugs.debian.org/549987">Debian bug #549987</a></span> -
halevt - add missing dep on policykit (bonus: QA upload with misc
fixes)</li>
</ul>
<p>No particular remarks, but a long overdue <strong>tip of the
week</strong>: the <a href=
"http://bts.turmzimmer.net/details.php">turmzimmer BTS</a>
interface is a great tool for bug squashing. Still, it has a issue
with comments which can slow down some activities, but which you
can help getting better! First of all you should know that
<em>comments are per-package and not per-bug</em> (which might not
be obvious, especially since often packages listed on the page have
just one bug per-package). That means that <strong>you should
generally mention the bug you are referring to when you post
comments</strong>, unless the comments are really
package-specific.</p>
<p>Additionally, <strong>old comments are persistent</strong>, so
you might get baffled by old comments that "invalidate" current
issues. So, if you notice a comment that predates the actual bug
numbers, <strong>please remove the comment</strong> by editing it
and stating "no comment" in the form.</p>
<p>Ah, happy new year (in case you care about sharp, calendar-based
time partitions).</p>