Category: PlanetDebian

Resurrecting “Debian package a day” ?

Posted on by lucas

A long time ago (until Nov 2004), there was this good blog which described one cool Debian package every day. It allowed to discover a lot of interesting software, but it suddenly stopped being updated.

It would be nice to resurrect this. A team of editors could work on this, and readers could submit new entries. Editors wouldn’t need to be Debian users : we could have Ubuntu users too, and it would be a nice way to determine what are the things that have been packaged in Ubuntu that we should (but don’t) have in Debian yet.

Leave a comment if you would like to dedicate some time to this (either as an editor, or as a regular submitter of entries). If there’s enough manpower, I’ll try to setup a mailing list or something to discuss the minimum infrastructure we would need.

When Ubuntu users discover that unofficial repositories can be harmful

Posted on by lucas

Unofficial APT repositories are a PITA in the Ubuntu community. Most users use stable release (see previous post about that) since Ubuntu development releases tend to be much more bleeding edge than Debian unstable. But users still want the newest software, so they use unofficial repositories. There are lots of posts about private repositories on Planet.ubuntu-fr.org, and it seems to be the same on other local planets.

Recently, somebody posted a sources.list file with a huge list of unofficial repositories. The maintainer of one of these repositories, Jοhan Kiviniemi, was surprised to be in this list without even being contacted first. He chose a good answer: he uploaded a package with cool new default wallpapers. He also wrote a detailed explanation, with which I couldn’t agree more.

But this story raises a question: why do all these people work on their unofficial repositories, instead of filing and fixing bugs, improving the official packages, and getting their packages into Ubuntu ? It’s a shame that so much manpower is lost on such stuff.

PS: Johan Kiviniemi seems to have a lot of good opinions. :-)

List operators on files in shell ? (updated)

Posted on by lucas

I often need to do list-like operations on files in shell, for example:

  • substract lines in one file from the lines in another file
  • add lines from two lines, suppressing duplicates
  • keep only lines which are not in both files
  • keep only lines which are in both files
  • etc

Such operations are easy to do with a combination of sort, uniq, cut, diff, etc. But they are so basic operations that it is a bit annoying to write the small shell script each time I need to do one of them.

Isn’t there a tool out there already providing all of them ?

Also, it would be great if such operations could be achieved considering only the first n characters or words (a bit like uniq -w, or the removed uniq -W option). It would be an easy way to do :

i1 c1
i2 c2
i3 c3
i4 c4

minus

i2
i4

Comments are opened.

Update: many people pointed me to moreutils‘ combine. It looks good, bug not exactly what I need, so I filed wishlist bugs #398187 (combine: provide aliases for set theory operators) and #398193 (combine: allow to compare only on a subset of the lines). I won’t have time to provide patches, so if somebody want to work on them …. :-)

Feature request: confirmation for non-member posts in mailman

Posted on by lucas

There are basically two kinds of setups for mailing lists managed using Mailman, regarding posts from non-members :

  • Accept posts from non-members. This lead to quite a lot of spam on the list, but also to no work for the moderators.
  • Put posts from non-members in a moderation queue. This result in a spam-free mailing list, but also in a lot of work for moderators, and in posts delayed for days.

It would be great if Mailman could ask the sender for confirmation (either email-based or web-based) before accepting the mail or putting it in the moderation queue. This would greatly reduce the amount of spam on the list or in the moderation queue.

This is also known as Mailman feature request #673265. A similar feature has apparently been in Sympa for nearly 4 years.

Wiki-like editing of tables/spreadsheets to share QA meta-information about packages ?

Posted on by lucas

I’ve been working on archive rebuilds lately (rebuilding all etch packages inside etch). It generates a lot of data to analyze (failed build logs), and the work could easily be split between several developers.

For each package which fails to build, I add a line in a Gnumeric spreadsheet with the package name, the version I tried to build, the output of a script which tries to guess the reason for the failure using regexps, and the “resolution” (was a bug filed ? a new package not yet in testing ?) (example here)

Instead of doing this locally in Gnumeric, I’d like to do that online, using wiki-like editing, so other people could investigate different failures concurrently.

My ideal piece of software would:

  • be efficient to use (something AJAX based would be great)
  • allow for line-based locking, so people can just lock the line they are working on
  • allow for CSV-export/import, so I could fetch the whole data, add new failures using a script, and import it back

Does this exist ? :-)

Some stats about packages build times

Posted on by lucas

I rebuilt all the packages in etch inside an i386 etch chroot on bi-Opteron systems with 2 Go of RAM. Here is some data about the build times for each package. They include the time needed to fetch the dependencies from a Debian mirror over NFS, so might have been overloaded during some builds, so it the build times might not be totally accurate, especially for the very short builds.
Two packages are excluded from the following stats because their didn’t complete their build: libmail-mboxparser-perl and camas.

17 packages took more than 1 hour to build. They are:

Package Build time (seconds)
openoffice.org 21537
linux-2.6.16 17859
linux-2.6 14833
gcc-4.0 9142
gcj-4.1 9062
gcc-4.1 7111
gnat-4.1 6910
installation-guide 6337
gcc-3.4 6022
octaviz 5735
gcj-4.0 5300
k3d 5294
openscenegraph 4851
ghc6 4670
glibc 4504
vtk 3954
atlas3 3759

The full list is available.

Most packages build very quickly:

Build time (s) Number of packages Total
< 30 5389 5389
30 – 59 2354 7743
60 – 119 1304 9047
120 – 499 873 9920
600 – 1799 92 10012
> 1800 40 10052

The total build time is 220.4 hours (that’s 9.2 days), the mean build time is 78.9s, the median build time is 27s.

Debian, Ubuntu, Mozilla® Firefox®, wearing hats, and Epiphany

Posted on by lucas

With my Ubuntu hat, I strongly regret that no Ubuntu developer (to my knowledge) stepped forward to point out the inaccuracies in Chris Beard’s (Mozilla Vice President of Products) Q&A on Mozilla Firefox in Ubuntu. Letting people bash Debian when Ubuntu gets so much stuff from Debian isn’t nice at all.

With my Debian hat, I really like how Mike Hommey chose to discuss facts, with references, in his reply to Chris Beard’s post. When it is possible, going back to the facts is really the best thing to do to avoid the usual FUD. It’s not really a surprise that this intelligent behaviour came from the Debian side.

I have been a very happy user of Epiphany since I made the switch from Firefox 3 months ago. I would recommend it to anyone still using Firefox who is tired of its slow startup times, and its lack of integration in the Gnome desktop.

Mozilla, Debian and Iceweasel: the Mozillian point of view

Posted on by lucas

During the Journées du Logiciel Libre 2006 (an excellent event, thanks to the organizers), I had long chats with people from Mozilla Europe (in a more constructive way than what others did). This is mostly second-hand information, since the well-informed guys from Mozilla Europe I talked with got their info from other Mozilla developers, so it might be slightly inaccurate, but still help to understand the issue. More details welcomed in comments.

The Mozilla Foundation goal is to prevent the web from becoming a proprietary web, by ensuring that Firefox, their product, has a big-enough market-share. I find it a bit disturbing to hear free software people speak about product and market-share, but well, OK. Of course, it’s quite difficult to achieve >20% market-share only with GNU/Linux users. :-)

They put a very high emphasis on the User experience. They want Firefox to look exactly the same on all platforms, even if some features (automatic plugin installation, automatic upgrades) do not fit well on a GNU/Linux system (such features don’t work with the Debian build).

They want to enforce their trademark to prevent attempts to ruin their reputation to succeed. After a question asked by Dave Neary (GNOME) to Tristan Nitot (president of Mozilla Europe), Tristan gave the example of this hacker who said he found critical security bugs in Firefox before admitting it was a joke. He also gave the example of Microsoft indirectly founding SCO. Dave Neary remarked that some people could probably be trusted (like distro maintainers). But, if I remember correctly, Tristan said that it was difficult to allow some people to use the trademark without allowing everybody to do so. Also, allowing Debian to use the trademark without allowing derivatives to do so is not possible (DFSG#8).

Iceweasel is considered a good thing inside Mozilla Europe (“It’s what we have asked them to do for a long time!“). However, some people are bitter about the fact that Debian seems to have chosen to use a gnu.org-hosted fork instead of just renaming the package to iceweasel.

During Tristan Nitot’s conference, I asked a question about length of security support (only 18 months for the 1.0 branch). The answer was that distros were supposed to upgrade to newer Firefox releases even on their stable releases (!) or to come and help with security support for stable releases. Also, the fact that Debian chooses to package Firefox following the FHS is considered a source of problems. Somebody claimed that Debian was the only distribution to package Firefox this way (seems strange, but I did not checked this claim). I’m not sure how this fits with other Mozilla-based browsers such as epiphany.

On a more technical side, they also claimed that Debian wasn’t properly collaborating with Mozilla, sending unusable 100000-lines patches for validation just before releases (haven’t checked this claim). It’s interesting to note that the same problem exists on the other side, with Mozilla releasing “security and stability” releases instead of just providing patches for the security bugs.

My personal conclusion is that Iceweasel is really a good thing, and is quite unavoidable, even if it seems that the Debian/Mozilla collaboration could maybe have been better. Let’s advertise the use of Iceweasel, Epiphany, and other Web browsers! :-)

Note : comments open for people willing to fix inaccuracies or provide references, not for a stupid childish flame-war like the one in the comment of this post. Please write your own blog entry and use a trackback if you want to provide a detailed answer!

Updates:

  • I forgot to mention that the Mozilla people talked about Debian-specific changes that changed frozen APIs, breaking extensions, and causing bug reports on b.m.o or misleading forum posts. (again, not verified)
  • Interesting blog post about the trademark issue here
  • Mike Hommey addressed most of the points I reported in this blog entry.

Random chat using XMPP/Jabber, anyone ?

Posted on by lucas

A Random Chat applet hit digg recently. It allows you to chat with a random stranger visiting the website at the same time as you.

It’s a good idea, but it would really be much better to have something similar based on Jabber (and maybe it could become a Jabber killer app’ ?)

Some thoughts:

  • It should be easy to get in the system, but slightly more difficult to get out of it : the main problem with the current website-based system is that it doesn’t work very well outside of flash-crowd periods. For example, you could be considered available for Random Chat as soon as you are “Available” or “Free for chat” on Jabber.
  • The system should provide strong anonymity (no direct messages between participating users to hide their JID) and allow for blacklisting to avoid the usual harassment problems.
  • The system should work with a classic Jabber client: no specific software or support for unimplemented JEPs should be required.
  • The system could include a tag-based system to be able to chat with people with similar interests or speaking the same language(s)

So, is somebody interested in working on this ? It would be quite easy to do with XMPP4R or another Ruby library. (This was from my list of things that I would really like to see implemented, but I won’t have time to work on it myself)

Related links:

Of bounties, donations and summers of code influence on volunteer participation

Posted on by lucas

Stuff like the Google Summer of Code, the GNOME Women’s Summer Outreach Program 2006, the Sourceforge donations system, or Dunc-Tank (an experiment to see how targeted fund raising can improve Debian) are generally considered a good ideas. However, experiments have shown that sometimes, paying volunteers decreases the overall participation. Luis Villa wrote about this a few months ago, and summarized like this:

When people do things for their own intrinsic goodness (i.e., for reasons other than payment), introducing payment can reduce the amount of invovement.

I urge you to read Luis Villa’s blog entry about this, and specifically the Motivation Crowding Theory: A Survey of Empirical Evidence paper.

Update (22/09) :

The point of this blog entry was “You should read this, it could help you make your own opinion about this stuff.”, not “Dunc-Tank bashing.”.

About Dunc-Tank specifically, I don’t think that it desserves all the criticisms it has gone through recently, because :

  • It is an experiment. Its results will be discussed (I hope), and will help to better understand the consequences of such projects. Also, I like the fact that this experiment is taking place with Debian, because Debian hasn’t been the most innovative project lately.
  • It has limited scope: it’s only about paying two Release Managers for one month each, so it is unlikely to break totally the social dynamics of Debian. it’s not as if it was paying 400 people from 40 organizations without thinking too much about the social issues involved.
  • The team running Dunc-Tank is probably one of the best possible teams for this. Breaking Debian is probably very low on their priority list ;)

However, I would be more comfortable with Dunc-Tank if it’s goal was “Experiment the effects of fund raising on Debian”, and not “Pay developers to release etch in time” (dunc-tank.org doesn’t say this, but some articles in the press do .)

One remaining issue is: is paying the RMs the best way to experiment fund raising ? I have no opinion about that, mostly because I don’t know how the Release Team works internally.

Disclaimer: I am not a DD, so I haven’t read the debian-private@ thread about that.