This week-end I attended the Paris Mini-Debconf, which was really a great event, and a nice opportunity to meet everybody again.
I delivered a lightning talk on “Get involved! It’s not that hard!“, which was also a good excuse to mention the Debian packaging tutorial and the Debian Maintainer Dashboard.
The brand new machine for Ultimate Debian Database motivated me to do UDD-related work again, so I implemented an old idea: build a maintainer/team-centric dashboard relying on UDD, the Debian Maintainer Dashboard.
The idea is to expose as much useful information as possible about a maintainer’s packages, both in the traditional (Developers Packages Overview-like) “big table with all the info”, but also in a task-oriented listing (to answer the “ok, I have two hours for Debian, what should I do now?” question).
At this point, the Debian Maintainer Dashboard already brings several cool features (try it with my packages or pkg-ruby’s packages, or your own!):
- Reports buildd issues (failed builds)
- Upstream status monitor that works (UDD has its own)
- Knows about teams’ VCS (if your team uses PET) and display the current version in the VCS
- Lists packages you maintain or co-maintain, and also the package you showed interest for by subscribing to them on the PTS
Of course, as of now, it’s pretty ugly: that’s the “help needed” part of the post. I really suck at web design, and would really appreciate if someone would help me to turn it into something nice to use. Besides adding links and colors everywhere, it could probably be nice to add sortable tables, and to create tabs for “TODO items”, “Versions” and “Bugs” (and possibly Lintian, for example). Contact me if you are interested.
I like to think that archive rebuilds play an important role in Debian Quality Assurance and Release Management efforts. By trying to rebuild every Debian package from source, one can identify packages that do not build anymore due to changes in other packages (compilers, interpreters, libraries, …). It is also a good way to stress-test all packages that are involved in building other packages.
Since 2007, I had been running Debian archive rebuilds on the Grid’5000 testbed, a research infrastructure for performing experiments on distributed systems – HPC/Grid/Cloud/P2P. I filed more than 6000 release-critical bugs in the process.
Late last year, Amazon kindly offered us a grant to allow us to run such QA tests on Amazon Web Services. With SÃ©bastien Badia, we ported the rebuild infrastructure to AWS (scripts), and several rebuilds have already been carried out on AWS.
On the technical level, 50 to 100 EC2 spot instances are started, and then controlled from a master instance using SSH. On build instances, a classic sbuild setup is used. Logs are retrieved to the master node after rebuilds, and build instances are simply shut down when there are no more tasks to process. Several tasks are processed simultaneously on each instance, and when they fail, they are retried again with no other concurrent build on the same instance, to eliminate random failures caused by load or timing issues. All the scripts are designed to support other kind of QA tests, not just rebuilds.
Moving to Amazon Web Services will facilitate sharing the human workload of doing those tests. It is now possible for developers interested in custom tests to do them themselves (hint hint).
Next week, I’ll head to Strasbourg for Rencontres Mondiales du Logiciel Libre 2011. On monday morning, I’ll be giving my Debian Packaging Tutorial for the second time. Let’s hope it goes well and I can recruit some future DDs!
Then, at the end of July, I’ll attend Debconf again. Unfortunately, I won’t be able to participate in Debcamp this year, but I look forward to a full week of talks and exciting discussions. There, I’ll be chairing two sessions about Ruby in Debian and Quality Assurance.
If you are a Debian developer and need realtime interaction with an Ubuntu developer about the state of your packages in Ubuntu (or vice-versa), #debian-ubuntu on irc.oftc.net might be useful. I had forgotten about that channel, but it resurfaced during the discussions about improving communication between both projects.
I recently (during a UDS lightning talk) discovered EtherPad. It’s a collaborative editor (like gobby), but uses a browser instead of a standalone application. It’s free software (Google open sourced it after buying the company that was developing it), and there’s a free online instance at ietherpad.com. Setting up a new pad is as simple as going to http://ietherpad.com/foo and clicking Create Pad. It’s written in Java, and not packaged in Debian (yet).
The Debian GSOC admins have made it clear that it is possible for DDs to be selected as GSOC students (even if people who are not Debian contributors will be prioritized). So, if you are a student, a Debian Developer, and interested in getting paid to work on Debian during the summer, it’s a very good idea to apply! For the details, see this blog post.
Note: the goal of this post is not to start a flamewar, but to make sure that everybody is fully aware of the unrestricted selection process. Since we are going to accept DDs as students anyway, let’s at least try to get the best applications.
I’ve been playing with virtualization, and KVM in particular. However, I’m running into an interesting problem. Below is how Ubuntu Netbook Remix look inside my KVM (either using virt-viewer, virt-manager or directly KVM to display the VM). Note how the top panel is fine. I’m using KVM 88 from experimental (but I had the same problem with KVM 85 from unstable), the cirrus video driver inside the VM, and an up-to-date karmic VM.
Has someone ran into that problem already? If yes, where is it tracked? I’m been failing to find the correct search keywords so far.
I recently realized how nice the Packages Tracking System is for upstream developers who want to follow the status of their software in Debian. By subscribing, they can easily monitor (and reply to) bug reports, and the general status of their software in Debian. I’m trying to help with coreutils maintainance, and it’s great to see upstream developers answer directly to bug reporters on Debian.
So, maintainers, tell your upstreams about the PTS! ;)
It might be a good idea to actually mention that use case on obvious places (not sure what the obvious places are, though).
A few months ago, I asked a set of questions on development mailing lists of a few GNU/Linux distributions. This resulted in very interesting discussions. As promised back then, all the answers from all distros I contacted can be read on the web or as an mbox file.
Also, Freedesktop.org kindly agreed to host a mailing list to ease discussions between distributions, and act as a central point of contact. You can subscribe, and post to distributions at lists dot freedesktop dot org.
This mailing list is for people involved (or interested) in the development of distributions. Questions that are on-topic are both technical and social/organizational issues, like:
- How do you achieve graphical boot in your distro? Do you use some kind of dependancy-based or events-based boot?
- How do you package both ruby 1.8, ruby 1.9 and jruby, or handle KDE vs KDE4?
- Do you use a system that gives a limited set of rights to new contributors?
Off-topic stuff obviously include trolling about which distribution is the best one, or user support.
Don’t hesitate to forward this announcement to all interested parties. Let’s make this mailing list something useful together!
Also, I really apologize for procastinating announcing this list for sooo long. I’m really good at procastinating interesting stuff, it seems.