tags/qazack's home pagehttp://upsilon.cc/~zack/tags/qa/zack's home pageikiwiki2014-02-27T19:31:05Zmoar stats for sources.debian.nethttp://upsilon.cc/~zack/blog/posts/2014/02/moar_stats_for_sources.debian.net/2014-02-27T19:31:05Z2014-02-27T19:22:00Z
<h1>Debian: watch your stats!</h1>
<p>Over the past few weeks, myself and Matthieu Caneill have worked
quite a bit on <a href=
"http://anonscm.debian.org/gitweb/?p=qa/debsources.git"><strong>Debsources</strong></a>.
As we have now deployed most of the new features on <a href=
"http://sources.debian.net">http://sources.debian.net</a>, it's
time for another <em>"What's new with Debsources?"</em> blog post.
Here is what's new:</p>
<ul>
<li>
<p>Debsources now knows about Debian <strong>suites</strong>, i.e.
which package is in which "release" (stable, testing, unstable,
...). This knowledge is already useful for some of the other
features below and will be used more in the future.</p>
</li>
<li>
<p><a href=
"http://upsilon.cc/~zack/blog/posts/2013/09/sources.debian.net_-_advanced_search_and_other_news/">
since last summer</a> Debsources has been running
<strong>sloccount</strong> on all unpacked source packages,
together with ctags and du, but the resulting information wasn't
exposed on the Web. This is now fixed. Each package now has an
<strong>infobox</strong> (<a href=
"http://sources.debian.net/src/linux/3.2.54-2">example</a>) which
shows: disk usage, archive area, suites, and sloccount with
per-language breakdown. The new infobox also subsumes the old puny
list of package links.</p>
<p>You can easily embed the infobox in other webapps if you need to
(<a href=
"http://sources.debian.net/embed/pkginfo/linux/3.2.54-2/">example</a>).
Check the <a href="http://sources.debian.net/doc/url/">URL scheme
doc</a> for more info.</p>
</li>
<li>
<p>Debsources now gathers and plot accurate Debian sources <a href=
"http://sources.debian.net/stats/"><strong>statistics</strong></a>,
both overall and per-suite, in both snapshot and <strong>historical
trends</strong> flavors.</p>
<p>(Yeah, I know, the charts are not particularly good looking ATM,
but that's easy to change without impacting the rest. So if you're
a <a href="http://matplotlib.org/">matplotlib</a> artist and
willing to help, please step forward!)</p>
</li>
<li>
<p>many changes have been going on also at the
<strong>plumbing</strong> layer to make the service less resource
hungry and more maintainable, in view of a migration to the
official Debian infrastructure --- which I've in the meantime
started discussing with DSA. Some highlights:</p>
<ul>
<li>
<p>Debsources now has a rather comprehensive <strong>test
suite</strong>, built using <a href=
"https://nose.readthedocs.org/en/latest/">Nose</a>. Most notably,
we do test full update runs down to source unpacking (of a small
subset of a Debian mirror), DB injection, and plugin execution ---
which is quite neat.</p>
</li>
<li>
<p>the updater is now much faster (about 2x) and might require, in
pathological cases, 10x <em>less</em> memory than before. Memory
usage now caps at around 300MB, even when injecting ctags for large
packages such as linux, chromium, and libreoffice.</p>
</li>
<li>
<p>the DB schema went through several refactoring cycles, and now
uses a separate <strong>file table</strong> to index all known
source file paths. In the past path information were duplicated
across the checksums and ctags tables, not only wasting DB space,
but also making the presence of file information conditional on the
enablement of at least one of the two corresponding plugins. This
is now fixed --- and migrating the full DB has been quite "fun".
Unfortunately, we've also added quite a few large-ish indexes,
resulting in no significant overall changes in DB size (currently
at ~50GB), but at least in much faster queries <img src=
"http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" /></p>
<p>The next step on this front will be the addition of path-based
searches, using the excellent Postgres <a href=
"http://www.postgresql.org/docs/9.1/static/pgtrgm.html">trigram
indexes</a>.</p>
</li>
</ul>
</li>
</ul>
<p>Want more? Sure, we'll be happy to! But it'll happen faster if
you <a href=
"http://anonscm.debian.org/gitweb/?p=qa/debsources.git;a=blob;f=BUGS;hb=refs/heads/bugs">
help</a>. Speaking of which: we've got Debsources into the <a href=
"https://wiki.debian.org/DebianFrance/NewContributorGame"><strong>new
contributors game</strong></a> (see <a href=
"https://lists.debian.org/debian-devel-announce/2014/02/msg00009.html">
announcement</a>) and we're looking forward to mentor new
contributors.</p>
sources.debian.net - advanced search and other newshttp://upsilon.cc/~zack/blog/posts/2013/09/sources.debian.net_-_advanced_search_and_other_news/2013-09-17T16:00:53Z2013-09-17T16:00:53Z
<h1>all your ctag (and checksum) are belong to us</h1>
<p>A few months after the <a href=
"http://upsilon.cc/~zack/blog/posts/2013/07/introducing_sources.debian.net/">initial
announcement</a>, here are some news about the <a href=
"http://sources.debian.net">sources.d.n</a> service. I've been late
in blogging this, but most of it has been implemented by myself and
Matthieu Caneill during <a href=
"http://debconf13.debconf.org/">DebConf13</a>, which has been a
great DebConf, totally exceeding my expectations (and they were
already fairly high!).</p>
<p>First, you might have noticed some <em>user-visible
changes</em>:</p>
<ul>
<li>
<p>there is now an <a href=
"http://sources.debian.net/advancedsearch/"><strong>advanced
search</strong> page</a>, which complements the already existing
<a href="http://codesearch.debian.net/">regex code search</a> with
the possibility of searching source files by their
<strong>sha256</strong>, or the <strong>ctags</strong> defined
therein</p>
</li>
<li>
<p>on the same topic, when browsing through a package and using
regex search, you'll now search by default within <em>that</em>
package, allowing to focus your searches more easily than before.
(You can easily override this by editing the search box and
removing the <code>package:</code> predicate.)</p>
</li>
<li>
<p>for the data geeks (or the wannabe host), there are now <a href=
"http://sources.debian.net/about/stats/"><strong>disk usage
stats</strong></a> (note that they don't include the database size,
though, see below for that)</p>
</li>
<li>
<p>the website also got a significant <strong>facelift</strong>, as
part of which we have moved the detailed explanations of what the
service is about out of your way. You now immediately get to the
various browsing options.</p>
</li>
</ul>
<p>On the other hand, <em>under the hood</em>:</p>
<ul>
<li>
<p>to implement ctags and sha256 searches we needed a serious DBMS,
so we switched from SQLite to <strong>PostgreSQL</strong>.</p>
<p>Again, for the data geek: storing ctags/sha256 for all of
sources.d.n content with decent indexes takes about 37 GB, for
about 160 million rows in the ctags table and 20 million rows in
the checksums one. (Currently filenames are duplicated between the
two tables so, probably, the DB disk size might be reduced
some.)</p>
</li>
<li>
<p>together with the switch to a serious DBMS, the update logics
has been completely rewritten in Python (from Bash...), and should
now be entirely transactional.</p>
</li>
<li>
<p>... and given it was going to be Python anyhow, better to enjoy
what it has to offer, no? So there is now a <strong>plugin
mechanism</strong> that makes it easier to add extra data
extractors, triggering them at each package update. Currently there
are plugins for sha256sum, ctags, and sloccount (even though the
latter is not yet exposed via the web interface). An added benefit
of this is that if you want to deploy debsources elsewhere, you can
easily disable the most time consuming extractors: running ctags
<em>and</em> sha256sum on the fabulous 3 chromium/libreoffice/linux
is not for the faint of disks...</p>
</li>
<li>
<p>we now receive <strong>push updates</strong> from the Debian
mirror network, so that you'll get updates on sources.d.n as soon
as a package hits Debian mirrors (+ processing time, which is about
15-20 minutes on the average update run). Many thanks to Simon
Paillard and Adam Lackorzynski for their help in setting this
up.</p>
</li>
<li>
<p>thanks to a <a href=
"https://lwn.net/Articles/557371/">suggestion by kugel</a> we have
adopted <a href="http://www.geany.org/">Geany</a>'s conventions for
filetype detection, and we now take into account both file
extensions and shebang lines (when available)</p>
</li>
</ul>
<p>As you usual, your bug reports (and patches!) are more than
welcome, just check <a href=
"http://anonscm.debian.org/gitweb/?p=qa/debsources.git;a=blob;f=BUGS;hb=refs/heads/bugs">
BUGS</a> before reporting to avoid duplicates.<br />
That's all!</p>
introducing sources.debian.nethttp://upsilon.cc/~zack/blog/posts/2013/07/introducing_sources.debian.net/2013-07-05T07:38:01Z2013-07-02T14:28:14Z
<h1>all Debian source are belong to us</h1>
<p><strong>TL;DR</strong>: go to <strong><a href=
"http://sources.debian.net">http://sources.debian.net</a></strong>
and enjoy.</p>
<hr />
<p><a href=
"http://anonscm.debian.org/gitweb/?p=qa/debsources.git"><strong>Debsources</strong></a>
is a new toy I've been working on at <a href=
"http://www.irill.org">IRILL</a> together with <a href=
"http://matthieu-blog.fr/">Matthieu Caneill</a>. In essence,
debsources is a simple web application that allows to
<strong>publish an unpacked Debian source mirror on the
Web</strong>.</p>
<p>You can deploy Debsources where you please, but there is a main
instance at <strong><a href=
"http://sources.debian.net">http://sources.debian.net</a></strong>
(<code>sources.d.n</code> for short) that you will probably find
interesting. <code>sources.d.n</code> follows closely the Debian
archive in two ways:</p>
<ol>
<li>it is updated 4 times a day to reflect the content of the
Debian archive</li>
<li>it contains sources coming from official Debian suites: the
usual ones (from oldstable to experimental), <code>*-updates</code>
(ex volatile), <code>*-proposed-updates</code>, and
<code>*-backports</code> (from Wheezy on)</li>
</ol>
<p>Via <code>sources.d.n</code> you can therefore browse the
content of Debian source packages with usual code viewing features
like <strong>syntax highlighting</strong>. More interestingly, you
can <strong>search through</strong> the source code (of unstable
only, though) via integration with <a href=
"http://codesearch.debian.net">http://codesearch.debian.net</a>.
You can also use <code>sources.d.n</code> programmatically to
<a href="http://sources.debian.net/doc/api/">query available
versions</a> or <a href=
"http://sources.debian.net/doc/url/"><strong>link to specific
lines</strong></a>, with the possibility of adding contextual
<strong>pop-up messages</strong> (<a href=
"http://sources.debian.net/src/cowsay/3.03%2Bdfsg1-4/cowsay?hl=22:28&msg=22:Cowsay:See?%20Cowsay%20variables%20are%20declared%20here.#L22">example</a>).</p>
<p>In fact, you might have stumbled upon <code>sources.d.n</code>
already in the past few days, via other popular Debian services
where it has already been integrated. In particular:
<code>codesearch.d.n</code> now defaults to show results via
<code>sources.d.n</code>, and the <a href=
"http://packages.qa.debian.org/">PTS</a> has grown new "browse
source code" hyperlinks that point to it. If you've ideas of other
Debian services where <code>sources.d.n</code> should be
integrated, please let me know.</p>
<p>I find Debsources and <code>sources.d.n</code> already quite
useful but, as it often happens, there is still a lot <a href=
"http://anonscm.debian.org/gitweb/?p=qa/debsources.git;a=blob;f=BUGS;hb=refs/heads/bugs">
<strong>TODO</strong></a>. Obviously, it is all Free Software
(released under GNU AGPLv3). Do not hesitate to report new bugs
and, better, to submit patches for the outstanding ones.</p>
<h2>Acknowledgements</h2>
<ul>
<li><a href="http://matthieu-blog.fr/">Matthieu Caneill</a> is the
main developer of Debsources web front-end;
<code>sources.d.n</code> wouldn't exist without him.</li>
<li>others have already contributed patches to integrate
<code>sources.d.n</code> with other services, in particular:
<ul>
<li>many thanks to Michael Stapelberg (for
<code>codesearch.d.n</code> integration), and</li>
<li>Paul Wise (for PTS integration).</li>
</ul>
</li>
<li>a full list of <a href=
"http://anonscm.debian.org/gitweb/?p=qa/debsources.git;a=blob;f=AUTHORS;hb=HEAD">
contributors</a> is available and eagerly waiting for new
additions</li>
<li><a href="http://www.irill.org">IRILL</a> has kindly provided
sponsoring for Matthieu's initial development work on Debsources,
and offered both the server and hosting facilities that power
<code>sources.d.n</code></li>
</ul>
<p><strong>PS</strong> in case you were wondering: at present
<code>sources.d.n</code> requires <strong>~381 GB</strong> of disk
space to hold all uncompressed source packages, plus ~83 GB for the
local (compressed) source mirror</p>
mancoosi-contesthttp://upsilon.cc/~zack/blog/posts/2010/06/mancoosi-contest/2010-06-03T13:09:34Z2010-06-03T13:09:34Z
<h1>submit your own dependency-resolution issue, a-la popcon</h1>
<p><small>[ repost from the <a href=
"http://blog.mancoosi.org/index.php/2010/03/25/44-software-release-mancoosi-contest-to-submit-your-debian-based-upgrade-scenarios">
original</a>, with updates ]</small></p>
<p>During the question time of <a href=
"http://blog.mancoosi.org/index.php/2010/01/24/40-mancoosi-at-fosdem-2010">
my FOSDEM 2010 talk</a> about <a href=
"http://fosdem.org/2010/schedule/events/dist_deps"><strong>cross-distro
dependency resolution</strong></a> several interested people,
mostly sysadms, asked how they could contribute upgrade scenarios
to the <a href="http://www.mancoosi.org">Mancoosi project</a>. The
underlying idea is simple: we are working on <strong>improving
dependency resolution</strong> techniques, algorithms, and tools;
to that end we need a corpus of <strong>upgrade scenarios</strong>
where shortcomings of state of the art tools can be observed. We
already have quite some of such scenarios (partly provided by
members of the project, partly generated <em>in vitro</em>, etc.),
but we could use more.</p>
<p>So, I'm hereby happy to announce the public availability of the
<strong>mancoosi-contest</strong> package, for Debian-based
distributions. <code>mancoosi-contest</code> essentially offers a
wrapper, called <code>dudf-save</code>, that you can prepend to
usual invocations of package managers such as <code>apt-get</code>
and <code>aptitude</code>. What it does is to capture all package
meta-data concerning your request, as well as the request itself
and the package manager output. All these data are first compacted
using <a href=
"http://git.debian.org/?p=mirror/snapshot.debian.org.git;a=blob_plain;f=API;hb=HEAD">
snapshot.d.o hashes</a>, then collected into a DUDF document, and
finally (optionally) uploaded to a DUDF collector service. All in
all it is very similar to the <a href=
"http://packages.debian.org/sid/popularity-contest">popularity-contest</a>
architecture, but instead of collecting installed packages it
collects specific upgrade attempts.</p>
<p>The similarity of course extends to privacy concerns, which we
do take very seriously (censoring IP addresses and offering all the
software we write and run available under FOSS licenses for
scrutiny). Obviously, participation is completely optional and the
<code>mancoosi-contest</code> package is currently being <a href=
"http://mancoosi.debian.net">provided only unofficially by the
Mancoosi project</a> <small>(even though it is signed by my key, in
case you want a trust path from the Debian keyring)</small>.</p>
<p>All that said, if, one day, you feel like having stumbled upon a
challenging upgrade scenario, please consider contributing it using
<code>mancoosi-contest</code>. We, for once, would be grateful
<img src="http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" /> , and you will be
helping in improving the state of the art in dependency solving.
Some of the most interesting upgrade scenarios already received are
currently being used as material for the ongoing <a href=
"http://www.mancoosi.org/misc-2010/"><strong>MISC 2010
competition</strong></a>, which we plan to repeat in the
future.</p>
<p>Technically, <code>dudf-save</code> is still quite hackish and
while <code>apt-get</code> support is OK-ish, <code>aptitude</code>
support is sub-optimal. In particular it will work properly only
for "completely batch" aptitude sessions (or, better, it will not
catch any intermediate solving attempt that <code>aptitude</code>
goes through when interactively asking questions to the user).</p>
<p>You can <strong>get mancoosi-contest from <a href=
"http://mancoosi.debian.net">mancoosi.debian.net</a></strong>, i.e.
simply doing <code>apt-get install mancoosi-contest</code> after
having added the following APT repository to your sources.list:</p>
<pre><code> deb http://mancoosi.debian.net/debian/ unstable/
</code></pre>
<p><small>For the time being, bug reports can be sent <a href=
"mailto:zack@debian.org">to me</a>.</small></p>
Debian-based scientific computing at EDFhttp://upsilon.cc/~zack/blog/posts/2010/05/Debian-based_scientific_computing_at_EDF/2010-05-27T16:13:25Z2010-05-27T08:51:16Z
<h1>why Debian for scientific computing: a case study</h1>
<p>Yesterday I've been invited to visit <strong><a href=
"http://en.wikipedia.org/wiki/%C3%89lectricit%C3%A9_de_France">EDF</a>
<a href=
"http://research.edf.com/research-and-innovation-44204.html">R&D</a>
center</strong> at Clamart, near Paris. They wanted to discuss
their Debian usage and present some of the cool stuff they're
doing. The most interesting component is an in-house Debian-based
distribution called "<strong>calibre</strong>", which has been
<a href=
"http://2008.rmll.info/IMG/pdf/EDF-Informatique-Scientifique.pdf">presented
at RMLL 2008</a>.</p>
<p>Even though it is now growing desktop profiles (currently
deployed on about 1'200 desktops and counting), calibre was mainly
developed for clusters dedicated to <strong>scientific
computing</strong>. Current cluster deployments at EDF are not
<em>that</em> big, but still comprise hundreds of machines for
about 40 teraFLOPS, with their largest cluster in <a href=
"http://www.top500.org/">Top 500</a>. The main goal of calibre was
to quickly bring a complete cluster from the bare metal to
production state. The goal has been quite successfully achieved:
using Debian and <a href=
"http://www.informatik.uni-koeln.de/fai/">FAI</a> they get a
cluster of 200 machines ready for production in about 1 hour and a
half, installing more than 3'000 packages on each machine (as the
cluster will be used for heterogeneous purposes, rather than for a
handful of specific applications).</p>
<p>What I found most interesting of the visit are the
<strong>reasons for choosing Debian</strong> over other
(commercial) distros for their scientific computing purposes:</p>
<ul>
<li>
<p>They use a wide range of open source <strong>scientific
softwares</strong> <small>(some developed <a href=
"http://research.edf.com/research-and-the-scientific-community/softwares/softwares-44329.html">
in house</a>)</small>: according to their claims Debian is the
mainstream distribution with the <strong>largest offering</strong>
of such software, with the additional benefit that corresponding
Debian maintainers are experts of the software they package, so
that they can trust them. They have kudos for <a href=
"http://wiki.debian.org/Teams/DebianScience">Debian Science</a>,
which I'm happy to proxy.</p>
</li>
<li>
<p>They need to <strong>rebuild packages</strong> to trigger
specific optimizations for their clusters. On one hand, that
defeats the typical management argument of "commercial support"
that other distros offer, as rebuilding packages void support
guarantees.</p>
</li>
<li>
<p>On the other hand, it really helps them the focus on
<strong>quality</strong> that we do have on Debian: we fight
<strong><a href=
"https://en.wikipedia.org/wiki/FTBFS">FTBFS</a>s</strong> to death,
and people which need to rebuild our packages really appreciate
that.</p>
</li>
</ul>
<p>EDF is generally keen of contributing back to Debian (even
though the team behind calibre is still small), and I've been happy
to walk them through how they can contribute.</p>
<p>The last interesting feedback I've to share, is that they feel a
bit alone in what they're doing <small>(which is unsurprisingly,
given that their communication on the matter has been rather
limited thus far ...)</small>. Still, there is probably room for
synergies that can be better exploited among users with similar
needs. So, <strong>are you a cluster / scientific computing user of
Debian?</strong> Then <a href="mailto:leader@debian.org">let me
know</a>, and I'll be happy to get you in touch with EDF and other
users with similar interests.</p>
UDD - consolidating bazaar metadata for QA and data mininghttp://upsilon.cc/~zack/blog/posts/2010/05/UDD_-_consolidating_bazaar_metadata_for_QA_and_data_mining/2010-05-10T20:40:39Z2010-05-10T20:40:39Z
<h1>Eclectic paper on the Ultimate Debian Database</h1>
<p>A few months ago, I've co-authored with <a href=
"http://www.lucas-nussbaum.net/blog">Lucas</a> a <strong>paper on
<a href="http://udd.debian.org">UDD</a></strong>, which has just
been presented at this year IEEE's <a href=
"http://msr.uwaterloo.ca/msr2010/index.html">Mining Software
Repository</a> conference, continuing my recent tradition of
<a href=
"http://upsilon.cc/~zack/blog/posts/2009/11/Enforcing_type-safe_linking_using_package_dependencies/">
eclectic</a> <a href=
"http://upsilon.cc/~zack/blog/posts/2010/01/Preserving_privacy_with_Google_Docs/">papers</a>.</p>
<p>The paper is titled <em>The Ultimate Debian Database:
Consolidating Bazaar Metadata for Quality Assurance and Data
Mining</em> and is available for <a href=
"http://upsilon.cc/~zack/research/publications/msr2010-udd.pdf"><strong>download</strong></a>
from my <a href="http://upsilon.cc/~zack/research/publications/">publications</a>
page.</p>
<p>For Debian people already familiar with UDD there is probably
not much to learn from it, as the main target of the paper is the
community of scientists doing <strong>data mining on software
repositories</strong>. For them, UDD offers a valuable entry point
to Debian "facts", as data sources reflected in the database are
easily joinable together and to some extent already validated by
other UDD users (e.g. QA people). Nevertheless the <strong>first
two sections</strong> of the paper are probably of more broad
interest. There we have given our point of view on the so called
<strong>Debian Data Hell</strong>: why it exists, how it's related
to the nature of Debian and similar distros, etc.</p>
<p>I've already <a href=
"http://upsilon.cc/~zack/blog/posts/2010/01/kuhn_on_debian_ubuntu_and_the_culture_of_freedom/">
noted in the past</a> how that is also related to the
<strong>culture of freedom</strong> that in Debian we value not
only in our software, but also in our infrastructure and
procedures. We should just get rid of a bit of inertia, and total
world domination will then be just around the corner <img src=
"http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" /></p>
<p>I'm happy to conclude quoting the acknowledgments section of the
paper:</p>
<h2>Acknowledgments</h2>
<blockquote>
<p>The authors would like to thank all UDD contributors, and in
particular: Christian von Essen and Marc Brockschmidt (student and
co-mentor in the Google Summer of Code which witnessed the first
UDD implementation), Olivier Berger for his support and FLOSSmole
contacts, Andreas Tille who contributed several gatherers, the
Debian community at large, the "German cabal" and Debian System
Administrators for their UDD hosting and support.</p>
</blockquote>
gdebi needs youhttp://upsilon.cc/~zack/blog/posts/2009/09/gdebi_needs_you/2009-11-28T12:00:16Z2009-09-20T18:56:47Z
<h1>please help out with gdebi - a history of why</h1>
<p>Short summary: <strong>if you are looking for a way to help
Debian become a bit more user friendly, please take care of
<a href="http://packages.qa.debian.org/g/gdebi.html">gdebi</a> in
Debian</strong>.</p>
<p>I'm rather upset. So beware, rant ahead.</p>
<p>The reason dates back to the beginning of this afternoon, when a
friend of mine, GNU/Linux <strong>newbie</strong>, mailed me asking
for help with his brand new (to my astonishment) Debian Lenny
installation running the GNOME desktop environment. The request was
simple and common to a lot of our users: "how can I see videos on
YouTube and use Skype"?</p>
<p>Surely, the first (brief) explanation I gave was <em>why</em>
those pieces of software are not in Debian, because they are pieces
of <strong>evil proprietary software</strong>. Fair enough, usual
song and dance, that gets the message through. But than, given that
I personally care about releasing a completely free operating
system, but not necessarily in inhibiting the usage of any non-free
bits of software, I wanted to actually <strong>solve</strong> my
friend's problem.</p>
<p>Regarding <a href=
"http://packages.qa.debian.org/f/flashplugin-nonfree.html">flashplugin-nonfree</a>,
unfortunately it is not in Lenny. Two solutions to that: either
point him to <strong><a href=
"http://www.backports.org">http://www.backports.org</a></strong>
and explain how to use them from synaptic (not particularly hard).
Or give him a direct download link of the .deb coming from
backports.org.</p>
<p>It turns out that for Skype there is no such choice. Once there
used to be an APT-gettable repository for their debs, but it seems
to have vanished (or else I can't find it). Still, there is a page
from which you can download Lenny .debs. Given that for Skype the
choice is forced, I was tempted to simply reply to him with a
couple of link to .debs and solve his problem rather easily.</p>
<p>But wait. Once he has the two debs, <strong>how can he install
them</strong>? First attempt: "just click on them in Nautilus" (my
hope: "synaptic will do the right thing™). No way, it will fire up
file-roller. Second attempt: "install <strong>gdebi</strong> (using
synaptic), right-click on the deb, and choose ;open with gdebi'".
Seems to work, but no, you will be hit by <a href=
"http://bugs.debian.org/493352">Debian bug #493352</a>. (BTW, the
reason why you need the <em>right</em> click is <a href=
"http://bugs.debian.org/421096">Debian bug #421096</a>).</p>
<p>What makes me upset is that both bugs were there way before the
Lenny release and slipped through our QA knots. Nobody's fault, the
maintainer apparently lost interest (or time) package and stopped
caring about it. Happens all the time. But damn!, we will lose a
user the moment I tell him "you know, you need to open up a root
terminal". A few remarks: this rant is not about "we should invite
user to use non-free software"; it is not even about "we should be
more attractive to newbies"; it is just about the pity of losing
users <strong>like this</strong>, dumbly.</p>
<p>Concluding:</p>
<ol>
<li>
<p><strong>dear lazyweb</strong>, any idea of what can I suggest to
my friend to install the debs I'll point him to, without needing
the knowledge of a terminal?</p>
</li>
<li>
<p>gdebi in Ubuntu is ahead of lots of version wrt Debian, I'm
convinced that it fixes most outstanding issues (given that
upstream author is a Canonical employee). If you have some free
Debian-time slots (I currently don't) and you care about
newbie-accessibility, please consider <strong>helping out with
gdebi</strong>. He needs you.</p>
</li>
</ol>
<p>EOR (end of rant)</p>
<p><strong>Update 07/10/2009</strong>: gdebi is now fixed in
unstable \o/ , thanks to Michael Vogt and Luca Falavigna for
bringing back into sync Debian with upstream/ubuntu.</p>
wanna-build gains detection of uninstallable build-depshttp://upsilon.cc/~zack/blog/posts/2009/07/wanna-build_gains_detection_of_uninstallable_build-deps/2009-11-28T12:00:16Z2009-07-30T07:59:13Z
<h1>wanna-build, edos-builddebcheck-powered</h1>
<p>Cool hacks happen at debconf, as usual.</p>
<p>I've talked a bit about the research work we are doing in the
<a href="http://www.mancoosi.org">Mancoosi</a> project regarding
formal study of dependencies among (Debian) packages. All in all,
people in the project (not only me!) are also maintaining tools
inherited from the <a href="http://www.edos-project.org">EDOS</a>
project and in particular things like:</p>
<ul>
<li>
<p><a href=
"http://packages.debian.org/sid/edos-debcheck">edos-debcheck</a>
checks for the installability of packages given via APT's Packages
file. It has been <a href=
"http://edos.debian.net/edos-debcheck/">used daily for QA purposes
since a while now</a></p>
</li>
<li>
<p>edos-builddebcheck (shipped in the <a href=
"http://packages.debian.org/sid/edos-debcheck">same package</a>),
which is a wrapper around edos-debcheck (by coincidence, developed
at last year's DebConf by me and Ralf Treinen) which checks for
<strong>installability of build dependencies</strong></p>
</li>
</ul>
<p>Just yesterday <a href=
"https://www.joachim-breitner.de/blog/">nomeata</a> tortured
<a href=
"http://packages.debian.org/sid/devel/wanna-build">wanna-build</a>
to integrate edos-builddebcheck into it. That way,
<strong>wanna-build</strong> will discover in advance whether a
package is <strong>unbuildable due to uninstallable
build-deps</strong>; if this is the case, the package will be put
in a new state (which will be rechecked at archive change) without
bothering the buildd maintainer.</p>
<p>Very cool, thanks nomeata!</p>
PTS layout changeshttp://upsilon.cc/~zack/blog/posts/2009/07/PTS_layout_changes/2009-11-28T12:00:16Z2009-07-24T00:22:51Z
<h1>no more tables, more accessibility, more compact layout</h1>
<p>As you have probably noticed already, the <strong><a href=
"http://packages.qa.debian.org">PTS</a> layout have
changed</strong>, mostly as a consequence of some hacking of the
last hours here at <a href=
"http://debconf9.debconf.org">DebCamp</a>.</p>
<p>The biggest change has fixed the long outstanding <span class=
"strike"><a href="http://bugs.debian.org/348971">Debian bug
#348971</a></span>, by moving the PTS away from a table-based
layout to a <strong>CSS-based layout</strong>. That means more
accessibility (tables are for tabular data, full stop) and is going
to stay.</p>
<p>Then, based on some comments from <a href=
"http://my.opera.com/atomo64/">Raphael</a>, I've generally reworked
several layout bits to have a <strong>more compact layout</strong>.
The PTS needs to show a lot of information in a tight page, getting
rid of useless markup is quasi-mandatory.</p>
<p>There will surely be glitches, so <strong>I'm looking for
feedback</strong> (please use one of: a comment here, a mail, or a
proper bug report):</p>
<ul>
<li>
<p>If you find <em>terribly ugly pages</em> please point me at
them. Screenshots might help, as glitches can be
browser-dependent.</p>
</li>
<li>
<p>If you were using the <a href=
"http://wiki.debian.org/qa.debian.org/pts/SoapInterface">SOAP
interface</a> please check that everything still work. I've tried
to be careful in not breaking the <a href=
"http://upsilon.cc/~zack/blog/posts/2008/11/PTS_SOAP_interface/">designed
microformats</a>, but something could have slipped through.</p>
</li>
<li>
<p>As a <span class="strike">silly</span>personal itch I haven't
been able to scratch, I was looking for an icon for the bug graph,
but didn't find the one I <em>really</em> wanted. Namely, an
<strong>old GNOME emblem icon</strong> (maybe 2 releases ago?)
depicting a <strong>stock exchange histogram</strong> going up and
up: that would have been <em>perfect</em> for bug graphs <img src=
"http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" /> If you remember that emblem
and know where to find it please let me know.</p>
</li>
</ul>
<h2>Where to?</h2>
<p>I think that for DebConf my PTS hacking is now over. I've some
work duties to complete in spite of being here, and the usual very
interesting talk are arriving really soon now. Still, here are a
couple of ideas I'll sooner or later consider for
implementation:</p>
<ul>
<li>
<p><strong>Reduce the text of messages</strong> (TODO and problem
items) emitted by the PTS. Now they are paragraphs with full
sentences, which quickly become useless. The way to go is have
short texts (a-la lintian messages) paired with links which trigger
explanatory pop-up. I already have a pure CSS prototype of that
which looks nice, but deploying it means reviewing all current
messages, which are quite a lot ...</p>
</li>
<li>
<p>Play with <strong>binary package display</strong>. Currently the
PTS has no description whatsoever about the package it is
describing. That's normal, as we have no such thing as source
package descriptions <small>(even though <a href=
"http://blog.djpig.de/">djpig</a> proposed such an extension a
while ago, and I'd love to have it)</small>. I'd like to try out
with a central block showing one binary-package per tab with
package descriptions and per-binary bug counts (currently on the
bottom left). I surely do not want to get in the way of <a href=
"http://packages.debian.org">package.d.o</a>, but what is already
there can be shown more prominently and exploited to better explain
what a given source package is about.</p>
</li>
</ul>
<h2>Kudos</h2>
<p>Thanks to Raphael Geissert for layout tips and to Enrico Tassi
for CSS guidance (yes, you should also blame him for upcoming
ugliness <img src="http://upsilon.cc/~zack/smileys/smile.png" alt=":-)" /> )</p>
l10n status in the PTShttp://upsilon.cc/~zack/blog/posts/2009/07/l10n_status_in_the_PTS/2009-11-28T12:00:16Z2009-07-22T14:00:45Z
<h1>i.e. archeology in the PTS bug logs</h1>
<p><a href=
"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=206363#69">From
the log of a bug I've just closed</a>:</p>
<pre><code> On Wed, Aug 20, 2003 at 12:45:41PM +0200, Martin Quinson wrote:
> I was wondering if it would be possible to add a new box to the
> package status page about the status of translations in that
> package.
... and finally, this is done!
The PTS now shows l10n status in 2 ways:
- a link on the "other links" section pointing to an i18n.debian.net
status page. The link is there only if the package is known to
i18n.d.n; it is there, it is also shown the "progress" of
translations for both Debian-specific and non-Debian-specific
strings
- if the Debian-specific string translation status is not complete, a
TODO item is added to mention that that should be fixed
</code></pre>
<p>That was the oldest outstanding bug reported against the PTS, a
vintage bug of 2003. <code>\o/</code></p>
<p>Many thanks to Nicolas François which took care of the <a href=
"http://i18n.debian.net">i18n.d.n</a> side of the integration.</p>
<p>Also, his proposal of <a href=
"http://i18n.debian.net/l10n-pkg-status/pkglist">"API" between the
PTS and i18n.d.n</a> made me realize an important point I'll re-use
in the future: when the PTS should link to some external data
provided (which is basically always the case), it is better to have
the external service provide the links to you in the usual index
file: that way the links can be changed by the data provider
without needing code changes in the PTS.</p>