I’m really happy to be able to attend DebConf11. It will be my third DebConf. I hope it will be as productive and enjoyable as past editions I’ll arrive on July 20th and stay until the end of DebConf.

See you all there soon!

It seems that Tunisia hosts a new shiny complete Debian mirror since a few days. It’s available at http://debian.mirror.tn. It even has all release architectures, which was a good surprise. Possibly, this new mirror will get its ftp.tn.debian.org some day if it implements all the requirements (which are listed here). As far as I know, this is the second complete Debian mirror in Africa. The first one is hosted in South Africa. Algeria hosts a Debian mirror too, but has i386 only. http://debian.mirror.tn had even a complete debian-cd/ directory when I had a look at it last Friday, but it disappeared over the week-end. I do wonder if it will come back at some point. It would make a lot of people happier, in my opinion.

This new mirror is hosted by ATI (Tunisian Internet Agency), a government agency which organizes anything that has something to do with Internet (IP addressing, interconnection of ISPs, mail gateways, main registrar of .tn domain extension, …). During Ben Ali’s era, they were known for Internet censorship. But, it seems that censorship was controlled directly by the palace. Since the revolution in Tunisia, ATI tried to clean his name and start a “new life”.

At the same location, they also host other mirrors among which we can find: Ubuntu, Mozilla, Eclipse, CPAN, Apache and Fedora. So, I think I’m not mistaken to say that there is a real intention to support Free Software. I hope they’ll be able to go further and provide hosting for Free Software Clubs/Groups in Tunisia, or even help to organise FOSS events.

Anyway… It’s nice to know that I’ll have a decent Debian mirror to use this summer from Tunisia

The revolution continues… stay tuned!

Le prochain qui fera un scandale au Parti Socialiste aura affaire à Martine Aubry !

P.S.: Photo trouvée sur le site de 20minutes.fr. Elle montre Martine Aubry donnant le départ de la route du Louvre à Lille, le 15 mai 2011.

Well, I still don’t feel ready enough to go back to (real) work. So, once more, I had to get my fingers on something to hack and I picked the Buildd Status Pages once more. It’s not my favorite project, but I decided to implement the few remaining ideas and get (temporarily) done with it. So, here we are with new features (and a few bug fixes):

• Add option to show (co-)maintained packages (Closes: #559515, #507782). It takes as input two files (Maintainers and Uploaders) to find the list of packages. Unfortunately, they contain binary packages (and particularly architecture “all” packages) that wanna-build doesn’t know anything about. On buildd.debian.org, I don’t have enough data (yet) to filter out that list manually. Ideally, my input should be a list of sources packages with at least one binary non architecture “all” packages only. Anyway… now, if you enter an email address, the script should parse those files looking for your list. Then, it adds a link to DDPO using that email address and replaces it by the list of found packages in the form, so that you can manually filter it.
  Update: I ended up filtering manually the list of packages. I keep only packages that wanna-build knows something about, on at least one architecture.
• Escape special HTML characters when we fetch a log (Closes: #621739). No comment on this one please At least, it was very easy to fix.
• Add a “raw” option to fetch.php so that it outputs only what’s in the log file, without any processing or escaping.
• Add a link to buildd.debian-ports.org, with the same list of selected packages and suite. Additionally, I’ve made some changes so that the deployment there becomes a bit easier.
• Try to produce valid XHTML code. I just went through errors I’ve seen and fixed them. The produced XHTML code is rather simple. So, I don’t need a real library for that yet.
• Add support for tail of logs. If your package fails to build on some architecture, the script will show you the last 15 relevant lines below the status table.

In my opinion, this new set of features deprecates totally the old version, since all (and more) is now covered and working with this new version. So, I think we can remove pkg.cgi and friends and put some redirection to the new scripts. If you disagree, please tell us ! I’ll submit a bugreport to QA folks asking them to change/remove links still present on the PTS and DDPO.

I think that this is the last set of changes before a while (except fixes). I hope that you’ll enjoy these new features as much as I do. If I still have some energy, I’ll try to spend it on -release stuff where there are several ongoing transitions (and many others waiting for acks, hints, analysis, etc…).

Last week, I had to put my daily (real) work off for a bit, to get some rest.  I took this occasion to implement a few ideas I had for the Buildd Status Pages. Mainly, I wanted to get rid of my external dependencies which are:

• https://buildd.debian.org/build.php which shows all build logs available for a package. It’s nice and simple, but old and not easy to read. In my opinion, it’s almost useless because it takes some time to realize (visually) what happened to the package (there are no colors to distinguish successful builds from failures, text is not aligned, etc…).
• https://buildd.debian.org/fetch.cgi which shows the content of a build log given a package, a version, an architecture and a time-stamp identifying the log file (you can see this as an example). The page works, there is no real need to rewrite it, modify it or whatever. It just does its job perfectly, but it was my last external dependency

Besides of getting rid of external dependencies, there were also a few feature requests (#618676, #612174, #518526) waiting for a while and it was good time to fix them. Hopefully, there are related to what I was fixing.

The final version is now deployed and can be used. The implemented changes are :

• From the regular package view, you have now a link to all logs available for that packages (click on Logs in the table), or all logs for a specific architecture (click on old in the table, for you preferred architecture).
• The listing of available build logs has now its own new page. The default listing shows everything, i.e. every version available and everywhere known architecture (just like the old page did before). But now, you get with that the build time and disk space consumed during the build, when available. Furthermore, it groups the logs by version so that it becomes easier to see that “all that group are logs for the same version”. And you can also show build logs for a specific architecture by choosing one (links in rows) ; or restrict on versions, in a similar way. And, of course, there are some additional colors in each row to distinguish successful builds from those who failed.
• The page that fetches the log is now available from other pages. And this removes the last external dependency.
• All pages have an appropriate HTML title set (yeah, it’s a shame that I didn’t fix that since the first deployment).

I think that I tested well enough this new version and it works okay. Nevertheless, if you encounter a bug or a strange behavior, please don’t hesitate to contact me (either by mail or on irc) or submit a bug report against buildd.debian.org.

The next steps (probably) are :

• add the last feature that pkg.cgi has which the ability to select a list of packages according to their maintainer (or co-maintainer).
• a better integration with P-A-S files.
• show tail of logs for build failures.
• ask wb-adm if build.cgi, bymaint.php, fetch.php, info.cgi are still needed/useful. If you do use use/need them, please speak up before they get removed.
• if you have any other idea, do submit a bugreport.

Recently [1], Zack, from an original idea of Jorge, asked the project whether it makes sense to have a debian instance of Shapado (a free software web application for question and answer support for our users). The idea was well accepted and http://ask.debian.net showed up quite quickly[2].

More recently, I stumbled upon an article[3] which announces the birth of the pretty same service but for Ubuntu users (in partnership with Canonical, Ltd.). It was known for some time as http://ubuntu.stackexchange.com. Then, it was redesigned (I guess) and offered a new domain name. The service runs Stack Exchange which is like Shapado but closed-source. It even runs on Windows Server and .Net. Admittedly, there is also http://ubuntu.shapado.com but it doesn’t seem very active (nor seems to be supported by Canonical).

In 2 days timeframe, both distributions gained the same service but they did it quite differently. I found this chain of events quite funny. And, really, I’m quite happy to be on Debian’s side (as always)

[1] http://lists.debian.org/debian-project/2010/09/msg00123.html
[2] http://lists.debian.org/debian-project/2010/10/msg00028.html
[3] http://blog.stackoverflow.com/2010/10/ubuntu-stack-exchange-is-askubuntu-com/

Recently, I started to write some web tool to track the status of ongoing transitions in unstable. I thought I could use some code from the Buildd status project (to see how it fetches the status for each package). Unfortunately, this caused some nightmares for some WB admin (because they used to rely on the generated BDB files and not the PGSql database, where the former is a snapshot of the latter stored in a funny format). Those BDB files were considered deprecated and status pages were looking for some love. Besides, the BDB files were kept in sync by regenerating them regularly (every 15 minutes, AFAIK). So, the information stored there was up-to-date only for a couple of seconds and then outdated, waiting for the next run to be updated.

Last weekend, I rewrote the status pages from scratch to make them use the PGSql database. I kept the same user interface (and pages’ arguments) to make it a drop-in replacement for the old one. Today, thanks to the WB admins, the new status pages replaced the old ones! There are no new visible features for now (except the backend and some links) but I have a list of new features that I intend to implement. These new features will be implemented in my local copy first and then integrated if WB admins want them. And, as some of you already noticed, the new status pages are aware of non-free packages (because it happens that the data is present in the PGSql database … thank WB admins for that!).

Since the recent announce of http://ubuntudiff.debian.net, some people started using it and asked for a few features. Lately, I’ve been working on it and tried to implement the following:

• Use a single page (instead of a small HTML page with a lot of JS)… well, that was easy
• Show the debdiff between the Ubuntu package and the Debian one: that was simpler than I first thought. Right now, it’s implemented and deployed [1]. When I first generated all patches, I realized how people can be crazy I had diffs larger than 60MB. So, I had to reduce that by keeping only diffs less than 200 lines per file. At the end, I had a little more than 2GB of patches (and html files) generated for ~2000 source packages (which is somehow reasonable). So now, below the changelog, there is a list of modified files and you can:
  • download a patch for each file, extracted from the debdiff,
  • or click on the file’s name to see the diff (if not too large, i.e. less than 200 lines)

  Note that red colored filenames denote files with too large diffs.

I’ll still have some details to fix like putting the “download patch” link on the left, fix the show/hide thing which is also activated when you click on “download patch”. Then, I’ll consider it feature-complete (almost) and won’t touch it again. My next game will be to write some tools to analyse or detect new transitions… if you want to play, let me know

As always, please test this new beta version of UbuntuDiff (and enjoy it :p)… and maybe, you may also report errors/bugs, if any

[1] http://ubuntudiff.debian.net/beta/

I got my air ticket. So, I’m able to say that I will go to DebConf10!

Ou encore mieux comme titre

BlackHat attacks RedHat

Après la faille de sécurtié dans Debian, c’est au tour d’un autre grand géant de Linux ! Le 22 Août était un très mauvais jour pour Fedora et RedHat. Ils ont subi une intrusion et ils ne savent pas exactement où est le problème … ou ne disent pas encore où est la faille.

Voici deux liens qui en parlent :

• http://linuxfr.org/~patrick_g/27082.html
• http://linux.slashdot.org/article.pl?sid=08/08/22/1341247
• et l’avis CERTA http://www.certa.ssi.gouv.fr/site/CERTA-2008-AVI-428/index.html

Le premier donne un récapitulatif des faits et le second est juste une alerte avec quelques liens vers le site de RedHat où on dit qu’il y a effectivement un problème.

Pour l’instant, RedHat a fait deux actions :

1. Faire un script openssh-blacklist-1.0.sh qui permet de détecter les paquets défaillants. L’intrus aurait signé sur les serveurs compromis des paquets d’OpenSSH. Le script a donc la liste des signatures des paquets compromis et regarde si l’un des paquets est sur votre système.
2. Mettre à jour les paquets d’OpenSSH (en corrigeant au passage un vieux bug concernant un cookie X11 non sécurisé, mais rien à voir avec l’histoire).

Pour l’instant, RedHat ne sait donc pas (d’après les éléments publiés) où est exactement la faille exploitée par l’intrus ! Elle a donc juste mis à jour les versions des paquets OpenSSH en croisant les doigts et en priant pour que la faille en question ne soit pas dans la nouvelle version uploadée.

C’est assez grave … vaut mieux mettre à jour son système, même si le correctif actuel est assez ridicule (à mon avis), mieux vaut ne pas tenter le diable :p

J’espère qu’on aura dans un futur proche le fin mot de cette histoire.

[1] http://www.redhat.com/security/data/openssh-blacklist.html