See you all there soon!

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!

• 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…).

• 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.

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/

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!).

• 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/