The
Mahara project has just moved to mandatory code reviews for every commit that gets applied to core code.
Here is a description of how
Gerrit Code Review, the peer-review system used by
Android, was retrofitted into our existing
git repository on
Gitorious.
(If you want to know more about Gerrit, listen to
this FLOSS Weekly interview.)
Replacing existing Gitorious committers with a robotThe first thing to do was to log into Gitorious and remove commit rights from everyone in the
main repository. Then I created a new
maharabot account with a password-less SSH key (stored under
/home/gerrit/.ssh/) and made that new account the sole committer.
This is to ensure that nobody pushes to the repository by mistake since all of these changes would be overwritten by Gerrit.
Basic Gerrit installationAfter going through the
installation instructions, I logged into the Gerrit admin interface and created a new "mahara"
project.
I picked the "merge if necessary" submit action because "cherry-pick" would
disable dependency tracking which is quite a handy feature.
Reverse proxy using NginxSince we wanted to offer Gerrit over HTTPS, I decided to run it behind an
Nginx proxy. This is the Nginx configuration I ended up with:
server
listen 443;
server_name reviews.mahara.org;
add_header Strict-Transport-Security max-age=15768000;
ssl on;
ssl_certificate /etc/ssl/certs/reviews.mahara.org.crt;
ssl_certificate_key /etc/ssl/certs/reviews.mahara.org.pem;
ssl_session_timeout 5m;
ssl_session_cache shared:SSL:1m;
ssl_protocols TLSv1;
ssl_ciphers HIGH:!ADH;
ssl_prefer_server_ciphers on;
location /
proxy_pass http://127.0.0.1:8081;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
Things to note:
- An HTTP to HTTPS redirection is not provided.
- The HSTS headers indicates to modern browsers that this URL should only be accessed via HTTPS.
- Only strong SSL ciphers are enabled.
- Before proxying requests to Gerrit, Nginx adds a few headers to identify the origin of the request. The Host header in particular must be present otherwise built-in Gerrit redirections will fail.
Mail setupTo enable Gerrit to email reviewers and committers, I installed
Postfix and used "reviews.mahara.org" as the "System mail name".
Then I added the following to
/home/gerrit/mahara_reviews/etc/gerrit.config:
[user]
email = "gerrit@reviews.mahara.org"
to fix the From address in outgoing emails.
Init script and cronFollowing the
installation instructions, I created these symlinks:
ln -s /home/gerrit/mahara_reviews/bin/gerrit.sh /etc/init.d/gerrit
cd /etc/rc2.d && ln -s ../init.d/gerrit S19gerrit
cd /etc/rc3.d && ln -s ../init.d/gerrit S19gerrit
cd /etc/rc4.d && ln -s ../init.d/gerrit S19gerrit
cd /etc/rc5.d && ln -s ../init.d/gerrit S19gerrit
cd /etc/rc0.d && ln -s ../init.d/gerrit K21gerrit
cd /etc/rc1.d && ln -s ../init.d/gerrit K21gerrit
cd /etc/rc6.d && ln -s ../init.d/gerrit K21gerrit
and put the following settings into
/etc/default/gerritcodereview:
GERRIT_SITE=/home/gerrit/mahara_reviews
GERRIT_USER=gerrit
GERRIT_WAR=/home/gerrit/gerrit.war
to automatically start and stop Gerrit.
I also added a cron job in
/etc/cron.d/gitcleanup to ensure that the built-in git repository doesn't get bloated:
MAILTO=admin@example.com
20 4 * * * gerrit GIT_DIR=/home/gerrit/mahara_reviews/git/mahara.git git gc --quiet
Configuration enhancementsTo allow images in change requests to be displayed inside the browser, I
marked them as safe in
/home/gerrit/mahara_reviews/etc/gerrit.config:
[mimetype "image/*"]
safe = true
Another thing I did to enhance the review experience was to enable the gitweb repository browser:
apt-get install gitweb
and to make checkouts faster by enabling anonymous Git access:
[gerrit]
canonicalGitUrl = git://reviews.mahara.org/git/
[download]
scheme = ssh
scheme = anon_http
scheme = anon_git
which requires that you have a git daemon running and listening on port 9418:
apt-get install git-daemon-run
ln -s /home/gerrit/mahara_reviews/git/mahara.git /var/cache/git/
touch /home/gerrit/mahara_reviews/git/mahara.git/git-daemon-export-ok
Finally, I included the Mahara branding in the header and footer of each page by
providing valid XHTML fragments in
/home/gerrit/mahara_reviews/etc/GerritSiteHeader.html and
GerritSiteFooter.html.
Initial import and replicationOnce Gerrit was fully working, I performed the initial code import by using my administrator account to push the exiting Gitorious branches to the internal git repository:
git remote add gerrit ssh://username@reviews.mahara.org:29418/mahara
git push gerrit 1.2_STABLE
git push gerrit 1.3_STABLE
git push gerrit master
Note that I had to temporarily disable "Require Change IDs" in the project settings in order to import the old commits which didn't have these.
To replicate the internal Gerrit repository back to Gitorious, I created a new
/home/gerrit/mahara_reviews/etc/replication.config file:
[remote "gitorious"]
url = gitorious.org:mahara/$ name .git
push = +refs/heads/*:refs/heads/*
push = +refs/tags/*:refs/tags/*
(The $ name variable is
required even when you have a single project.)
Contributor instructionsThis is how developers can get a working checkout of our code now:
git clone git://gitorious.org/mahara/mahara.git
cd mahara
git remote add gerrit ssh://username@reviews.mahara.org:29418/mahara
git fetch gerrit
scp -p -P 29418 reviews.mahara.org:hooks/commit-msg .git/hooks/
and this is how they can submit local changes to Gerrit:
git push gerrit HEAD:refs/for/master
Anybody can submit change requests or
comment on them but make sure you do not have the Cookie Pie Firefox extension installed or you will be
unable to log into Gerrit.
A new version of the digest package (which generates hash function summaries for
arbitrary (and possibly nested) R objects using any of the standard md5, sha-1, sha-256 or crc32 algorithms)
is now on CRAN.
Thanks to a patch by Mario Frasca, digest now contains a
second (exported) function 
So earlier on I posted about my work on 
Lately I have been working on the triggers feature of dpkg. I would like to share my plan and what I have done so far. I ll first explain what triggers are, the current problems, and the work I did to try to improve the situation.
Introduction
Dpkg triggers are a neat feature of dpkg that package can use to send/receive notifications to/from other installed packages. Those notifications take the form a simple string.
This feature is heavily used to track changes of packaged files in a list of predefined directories, and to update other files based on this. For instance, man-db is watching the directories containing manual pages so that it can update its cache (in 
From a packager s perspective
The implementation of triggers has several consequences on the status that packages can have.
Let s assume that the package A installs a file in a directory that is watched by package B (and that B is currently in the installed state). When A is unpacked, dpkg adds B to its Triggers-Awaited field and lists the activated trigger in B s Triggers-Pending field. Package A is in unpacked state, but B has been changed to triggers-pending .
When A is configured, instead of going to the installed state, it will go to the triggers-awaited state. In that state the package is assumed to NOT fulfill dependencies. However, B which is still in triggers-pending state does fulfill dependencies.
A and B will switch to installed at the same time when the trigger has been processed.
The fact that the triggers-awaited status does not fulfill dependencies means that some common triggers like man-db have to be processed regularly just to be able to ensure dependencies are satisfied before running the postinst of other installed packages.
But a package which ships a manual page can certainly be considered as configured when its postinst has been run even if man-db has not yet updated its cache to know about the new/updated manual page.
When you activate a trigger with the dpkg-trigger command you have an option 
I m proud to be able to announce a new stable release of 
The details regarding the new Grml release are available in the 
At April 30, I took over maintenance of of
I've got a few projects which are hosted in mercurial repositories. To deploy them I manually checkout the repository, create symlinks by hand, then update 
Weee! After the excellent experience last year in New York, I couldn t resist 
See you all in Banja Luka!
To make things louder, I will go to Wacken from 02.08.2011 until 07.08.2011, wonder to see some Debian people there :)
It's 2011. Computers are here for a couple of decades now, but they still don't help me with the most simple problems. I've been asked once again about a recommendation for a GroupWare and still don't know what to say. This are the simple requirements:
I just got off the phone with my Google Summer of Code mentor, Matt Zimmerman. Some things that we discussed were that Debian Developers are quite partial to the BTS. We agreed that using the BTS to store as much information as possible would be ideal. This would allow the Debian Maintainers to see the information that pertains to them, without them having to change their workflows to check a DEX dashboard.
Usertags are a rather useful feature that we did not utilize much when processing 
The lab features four web servers that will be merged into a single
web service with the help of keepalived. Since, keepalived now
supports full IPv6 support, we will also use IPv6 in our lab.
Here is the 
The problem
Some programs require root privileges for part of their work: most
notably Debian building tools such as dpkg-buildpackage or pdebuild. So, several command can be used to obtain real or fake root
privileges: su, sudo, fakeroot, etc. Among them, su is quite distinct,
because it only takes a quoted command to pass it to a shell. That is
why its interface is completely incompatible with the others':
My 
This summer, I ll be taking a bit of time off, moving back to San Francisco and starting 
