Thanks Lennart for mentioning Hugin! This is a really cool piece of software, allowing you to assemble a mosaic of photographs into a complete panorama.
I’ve created this 180 degrees panorama from 16 photos taken out of my window (3 rows: 6 + 6 + 4). The original picture is huge: 5000-something pixels wide and high and approximately 22Megs (jpg) fat.
If you want to test it yourself just
aptitude install hugin and make sure to get enblend from somewhere else (eg, debian-multimedia.org). If you don’t install enblend you don’t lose functionality, but the output will be of much lower quality. Thanks Florent Bayle for packaging hugin and Christian Marillat for packaging enblend!
Instead of the boring “package” queries, rng used to support ’till now, rng now supports all the queries our BTS supports:
- Returns all the bugs belonging to the PACKAGE
- Returns the bug with BUGNUMBER and loads it into the built in browser immediately
- Returns all the bugs assigned to MAINTAINER
- Returns all the bugs belonging to the SOURCEPACKAGE
- Returns all the bugs filed by SUBMITTER
- Returns all the bugs of SEVERITY. Warning this list is probably very long. Recognized are the values: critical, grave, serious, important, normal, minor and wishlist
- Returns all the bugs marked with TAG
Those queries are available on the command line too and behave exacly as if entered in the program: The syntax is:
rng [QUERY], where query is one of the above (and
rng a convenient shortcut to
An example: if you start
rng from:email@example.com, you’ll get the full list of all bugreports I’ve ever reported. Now you can filter the list to find all bugreports I’ve filed against, say: qgo… voila. It doesn’t get any easier than that, does it?
Those new queries and a few changes under the hood required quite a lot of refactoring in the code and I’m somewhat scared that I’ve introduced some new bugs. So I guess I should stop releasing so often (or for at least 10 days so rng can finally enter testing) and use the time to start writing some unit tests.
The migration was rather easy
sudo aptitude install bzr-svn
# patch (see below)
bzr branch svn://svn.debian.org/reportbug-ng # That's right I branch directly from a SVN repo!
# ignore the error
bzr push --use-existing-dir sftp://firstname.lastname@example.org/bzr/reportbug-ng
To get your own branch:
bzr branch http://bzr.debian.org/bzr/reportbug-ng/
Bzr-svn really makes it easy to migrate from svn to bzr… well, in theory. In practice we have #415721, but fortunately there is an easy workaround. Just temporarily apply this trivial patch:
--- /usr/share/pycentral/bzr-svn/site-packages/bzrlib/plugins/svn/__init__.py 2007-04-20 09:30:00.000000000 +0200
+++ /usr/share/pycentral/bzr-svn/site-packages/bzrlib/plugins/svn/__init__.py.new 2007-04-20 09:30:24.000000000 +0200
@@ -23,7 +23,7 @@
__version__ = '0.2.0'
-required_bzr_version = (0,13)
+#required_bzr_version = (0,13)
"""Check that bzrlib is compatible.
and life is good again.
The reason why I switched from a centralized to a distributed RCS was that I really like the option to do (small) local checkins and just do the “real” checkin when the work is done. In terms of BZR it means commits to my local branch for smaller changes and pushes back to the mainline for every major change. Oh, and it’s also nice always having the full repository data locally stored.
My requirements for the RCS were: it should be easy to use (no steep learning curve), well tested and somewhat mainstream. BZR fits quite well, especially since Ubuntu heavily relies on it for their launchpad stuff.
PS: Thanks to the alioth team for creating the BZR repository so quickly, it just took like 1 minute.
Currently there is a discussion about a new theme for debian.org going on on -www. Some people presented their ideas and build some mockups while others commented them.
I strongly suggest to let some professional designers and other (not necessarily Debian related) talented people create some mockups, to avoid moving from one outdated and rusty design to the next.
I wonder if we couldn’t open up the process a bit by starting some kind of contest. Skilled webdesigners could create some mockups and we could collect all those and let a vote decide which one to keep.
Looking at the current spam attack at our BTS I wonder how long it’ll take ’till the feature that our BTS is controllable via mail becomes a pain in the ass because of the spam.
I’m sure we have some spamfilter and some brave people controlling it, since in the last time it was relative quiet and spam free. But the current attack makes me think if we couldn’t raise the barrier for spam somehow. Not sure how to achieve that though.
shouldn’t we finally move away from this ugly MoinMoin theme? It’s not only the most ugly and spartan theme one could imagine (it even beats our main web presence in ugliness) — it does not even try to comply with some corporate design. The only things that remind me that I’m actually surfing a Debian related site are the URL and the words “Debian Wiki” on the top left. (There is a chance that the link-colors match the Debian-Red too, but I’m slightly colorblind, so I’m not sure)
MoinMoin can do better. Please look at Ubun… oops I mean bazaar’s homepage, they’re using MoinMoin too and it looks much more appealing than our wiki.