The following developers got their Debian accounts in the last month:

• Kamal Mostafa (kamal)
• Martin Bagge (brother)
• Kai Wasserb ch (curan)

Congratulations!

Gzip streaming in Python (or lack thereof) Consider this simple Python snippet:

#!/usr/bin/python
import gzip
from urllib import urlopen
zfd = urlopen("http://ftp.debian.org/debian/dists/sid/Contents-udeb.gz")
fd = gzip.GzipFile(fileobj=zfd, mode="r")
for line in fd:
    foobar(line)

It does not work: it turns out GzipFile wants to seek() and tell() on its file object:

$ /tmp/z.py 
Traceback (most recent call last):
  File "/tmp/z.py", line 8, in <module>
    for line in fd:
  File "/usr/lib/python2.6/gzip.py", line 438, in next
    line = self.readline()
  File "/usr/lib/python2.6/gzip.py", line 393, in readline
    c = self.read(readsize)
  File "/usr/lib/python2.6/gzip.py", line 219, in read
    self._read(readsize)
  File "/usr/lib/python2.6/gzip.py", line 247, in _read
    pos = self.fileobj.tell()   # Save current position
AttributeError: addinfourl instance has no attribute 'tell'

Oh dear... this really shouldn't be. Let's look around the internet for details:

Since opener.open returns a file-like object, and you know from the headers that when you read it, you're going to get gzip-compressed data, why not simply pass that file-like object directly to GzipFile? As you read from the GzipFile instance, it will read compressed data from the remote HTTP server and decompress it on the fly. It's a good idea, but unfortunately it doesn't work. Because of the way gzip compression works, GzipFile needs to save its position and move forwards and backwards through the compressed file. This doesn't work when the file is a stream of bytes coming from a remote server; all you can do with it is retrieve bytes one at a time, not move back and forth through the data stream. So the inelegant hack of using StringIO is the best solution: download the compressed data, create a file-like object out of it with StringIO, and then decompress the data from that.

Oh really, so it's a limitation of "the way gzip compression works", and the only way to work around this fundamental design flaw of gzip is to buffer the lot in memory or to a temporary file? [facepalm]

# Apparently, this is not how gzip compression works:
curl http://ftp.debian.org/debian/dists/sid/Contents-udeb.gz   zcat

This is not the first time that, after finding a frustrating spot in core Python things, looking around the internet for extra information has the effect of amplifying my frustration by destroying my expectations of common sense. What is the gzip module doing anyway?

    if self._new_member:
        # If the _new_member flag is set, we have to
        # jump to the next member, if there is one.
        #
        # First, check if we're at the end of the file;
        # if so, it's time to stop; no more members to read.
        pos = self.fileobj.tell()   # Save current position
        self.fileobj.seek(0, 2)     # Seek to end of file
        if pos == self.fileobj.tell():
            raise EOFError, "Reached EOF"
        else:
            self.fileobj.seek( pos ) # Return to original position
        self._init_read()
        self._read_gzip_header()
        self.decompress = zlib.decompressobj(-zlib.MAX_WBITS)
        self._new_member = False

Right, tell() and seek() in order to check if it's reached end of file. Oh dear... So, there's a flaw in the Python standard library, and:

• it is not explicitly mentioned in the module documentation, which just says "fileobj [...] can be a regular file, a StringIO object, or any other object which simulates a file".
• in basic Python learning material, we find a paragraph whose purpose is to explain that this is not Python's fault, but it is a fundamental limitation on the way gzip works.

I wish core Python documentation started properly documenting Python flaws so that one can code with language limitations in mind, insted of having to rediscover them and their work arounds every time.

Somewhat motivated by Geoff Huston's keynote at linux.conf.au 2011, I've decided to pull my finger out and make a foray into IPv6. My colo provider, where daedalus.andrew.net.au lives is IPv6-enabled, so a quick email to their support department, and boom, thanks to the black magic of SLAAC, and daedalus has an IPv6 /64. I still don't quite understand how it works. Comcast Business, on the other hand, doesn't seem to be quite so on the ball, so I've organised for a Hurricane Electric IPv6 tunnel to play around with at home. Next, I need to throw around a few AAAA DNS records, and then probably watch everything grind to a halt.

As you might know, Debian was one of the 20 organizations selected to participate in the first Google Code-in. We got a moderate success since we started preparing the contest very late (I joined as mentor/admin the very first day of the contest!). Because of this, unlike other organizations, we did not manage to engage interested students from the very beginning of the Code-in. Since we did not have too many Debian tasks the first days, we did not attract many students, and thus did not have very many throughout the contest. Given Debian tasks were mostly about improving and contributing to Debian, it was quite hard having tasks that did not require having a Debian installation and that made it difficult for many students to get involved. Also, until the last two weeks we did not have any translation task that could have attracted earlier students without too much confidence in their technical and English skills. Nonetheless, Debian got 39 tasks done:

• 9 write manpages tasks, resulting in ~35 manpages submitted to the BTS
• 14 triage bugs tasks, resulting in 42 bugs triaged in the BTS
• 4 new packages created
• 1 QA upload
• 1 video showing Squeeze s artwork
• http://wiki.debian.org/IntroDebianPackaging got translated into Spanish, Italian, Catalan and Romanian. And http://wiki.debian.org/UsingGit got translated into Italian.
• elinks got some nice icons
• dpkg got a small enhacement and a manpage for deb-src-control
• an initial draft of how to create a BOINC project with Debian
• and update-notifier-kde got a reboot option.

With about 30 students participating and at least one of the students has keep contributing to Debian after the contest! The contest was sometimes stressful with several students wanting their tasks to be reviewed at the same time, and the date was problematic due to the winter (or summer!) holidays but still I am quite happy with the final result :D Debian will be also participating again this year in the Google Summer of Code 2011. Join the soc-coordination mailing list and stay tunned if you want to participate as mentor or student.

Time for a third Debian XSF News issue! Debian XSF News #3

• Julien Viard de Galbert keeps on triaging bugs: TXBW9+10+11.
• After having taken some advice from Sven Joachim, I uploaded mesa 7.10 to experimental. I made both dh_install and dh_makeshlibs stricter, which triggered a FTBFS on i386 and sparc respectively. The former is fixed in git already, the latter still needs to be fixed. mesa 7.9 was already failing on non-Linux ports, and that s still happening for 7.10.
• I uploaded xkeyboard-config 2.1 to experimental. It is the source package for both xkb-data and xkb-data-udeb, which contain XKB configuration data. As mentioned in the changelog that s a big jump (3 upstream releases at once). While preparing it, I noticed a significant size increase: the udeb grew from 3.1MB to 3.5MB. Since size matters in the Debian Installer, I tried compressing the files shipped in the udeb, getting rid of a bunch of extra whitespaces and comments. A few tests seem to show no regressions, and the size went down to 2.6MB. Yay!.
• I did some heavy bug triaging myself, attacking some source packages: xkeyboard-config, mesa, and xorg-server. All in all, I managed to send 80+ mails in less than 16 hours, meaning 5+ answers per hour in average. I spent some more time after that, reaching 150+ mails in less than a week. Many bugs got closed, which can be seen on Mike Hommey s BTS graphs. The most interesting graph can be seen below.
• I closed a very old bug.
• I uploaded a new release candidate for xorg-server 1.9.4 to experimental. Nothing fancy on the upstream side (mostly XQuartz fixes), but on the Debian side, an update of the bug script. As a reminder, that s the script run by reportbug to collect information about the system. That should help us spot more common issues.
• The bug script update was cherry-picked into xorg-server 2:1.7.7-12 for unstable, along with two bugfixes. If everything goes fine, we might try and get it accepted for squeeze s r1 (in other words: the first point release for squeeze).
• I finally managed to get mesa to work on my Intel board enough to let me test wayland. Having a look at the architecture (it has pictures!) and at the FAQ should help interested folks to understand what this is all about. I opened an ITP for it, as well as one for libxkbcommon. The latter is already uploaded and sitting in NEW. We ll also need GL support in cairo, so I requested it.
• I should stress a few points: wayland is really at an early stage of development; all that is going to be shipped for now is a sample compositor implementation and a few sample clients for people to play with. Maybe wayland is going to replace X some day, but it should be noted that it comes with heavy requirements, like GL/EGL support. It s nice since many features and bugfixes are going to land in mesa, but that means that it s going to be available on a restricted class of hardware only, as opposed to X s ability to run more or less anywhere. This also means that early testers might need a pretty recent mesa snapshot. I ll try to make that easier, or at least well-documented. (Many thanks to Darxus for the review.)

It s been a year On a personal note, it s been a year to the day since I first looked into X. After having hacked on the Debian Installer to make it use X.Org instead of DirectFB, I did some heavy bug triaging, resulting in a drop in the xorg-server bug count in March. The same happened past week as written above, resulting in a second drop. In the meanwhile, the bug count remained more or less stable, since we try to reply quickly to new bugs, and since Julien Viard de Galbert does bug triaging on a weekly basis: One might ask: what does maintaining X mean?

• Packaging mostly everything X-related.
• Taking care of incoming bug reports as well as older ones.
• Working with upstream (which is going to be the subject of a later blog post), as well as coordinating with Ubuntu.
• Keeping an eye on the Graphical Installer.
• Writing documentation targeted at both users and maintainers.
• Advertising XSF s work.

Before you start reading: this post is only intended to test a plugin that I've just written to give PyBlosxom a txt2tags formatting support. The original txt2tag sample used here is available at txt2tag website. Mine with few changes is here.IntroductionWelcome to the txt2tags sample file.Here you have examples and a brief explanation of allmarks.The first 3 lines of the this file are used as headers,on the following format:

  line1: document title  line2: author name, email  line3: date, version

Lines with balanced equal signs = around are titles.Fonts and BeautifiersWe have two sets of fonts:The NORMAL type that can be improved with beautifiers.The TYPEWRITER type that uses monospaced font forpre-formatted text.We will now enter on a subtitle...BeautifiersThe text marks for beautifiers are simple, just as youtype on a plain text email message.We use double *, /, - and _ to represent bold,italic, strike and underline.The bold italic style is also supported as acombination.Pre-Formatted TextWe can put a code sample or other pre-formatted text:

    here    is     pre-formatted  //marks// are  **not**   interpreted 

And also, it's easy to put a one line pre-formattedtext:

  prompt$ ls /etc

Or use pre-formatted inside sentences.More CosmeticsSpecial entities like email (duh@somewhere.com) and URL (http://www.duh.com)are detected automagically, as long as the horizontal line:

---

^ thin or large v

---

You can also specify an explicit link with label.And remember,

A TAB in front of the line does a quotation.

More TABs, more depth (if allowed).

Nice.ListsA list of items is natural, just putting a dash ora plus at the beginning of the line.Plain ListThe dash is the default list identifier. For sublists,just add spaces at the beginning of the line. Morespaces, more sublists.

• Earth
  • America
    • South America
      • Brazil
        • How deep can I go?
  • Europe
    • Lots of countries
• Mars
  • Who knows?

The list ends with two consecutive blank lines.Numbered ListThe same rules as the plain list, just a differentidentifier (plus).

1. one
2. two
3. three
   • mixed lists!
   • what a mess
     1. counting again
     2. ...
4. four

Definition ListThe definition list identifier is a colon, followed bythe term. The term contents is placed on the next line.

orange

a yellow fruit

apple

a green or red fruit

other fruits

• wee!
• mixing lists
  1. again!
  2. and again!

TablesUse pipes to compose table rows and cells.Double pipe at the line beginning starts a heading row.Natural spaces specify each cell alignment.

heading 1	heading 2	heading 3
cell 1.1	cell 1.2	cell 1.3
cell 2.1	cell 2.2	cell 2.3

Without the last pipe, no border:

heading 1	heading 2	heading 3
cell 1.1	cell 1.2	cell 1.3
cell 2.1	cell 2.2	cell 2.3

Special EntitiesBecause things were too simple.ImagesThe image mark is as simple as it can be: [filename].

• The filename must end in PNG, JPG, GIF, or similar.
• No spaces inside the brackets!

OtherThe handy %%date macro expands to the current date.So today is 20110206 on the ISO YYYYMMDD format.You can also specify the date format with the %? flags,as %%date(%m-%d-%Y) which gives: 02-06-2011.That's all for now.

---

For quite a long time, I have a problem, that DNS in my OpenWRT box does not resolv local range on wan interface. Today I have leared that it is doing it in order to protect me:

dnsmasq[15709]: possible DNS-rebind attack detected: jmnet.czf

But hey, my wan interface has 10.* address and I want to resolve 10.* domains there! A little bit of googling revealed that this is caused by --stop-dns-rebind passed to dnsmasq. Okay, the easiest fix is to disable it. You need to change /etc/config/dhcp:

config 'dnsmasq'
        option 'rebind_protection' '0'

After reading source of /etc/init.d/dnsmasq I realized there is also way to whitelist some domains, what sounds like a slightly better idea. After fighting with syntax, I found the solution to be (again in /etc/config/dhcp):

config 'dnsmasq'
        list 'rebind_domain' '/czf/'

Next thing to explore is why is native IPv6 not working for me on the router though it should...

Filed under: English Openwrt 0 comments Flattr this!

A down-under talk on the role of Debian, A.D. 2011 I'm back from LCA 2011, which I've attended to share some thoughts about the role that Debian plays in the Free Software ecosystem, 18 years after its inception (yes, we are that old^Welder). The talk title---Who the bloody hell cares about Debian? [1]---was meant to be rather provocative. The idea was indeed to challenge the meme that, in the era of distributions that release every 6 months, a distribution with a release cycle of circa 2 years (like Debian, considering the past 5 years) is not a project that deserves your attention anymore. Is it really the case? In the talk I (obviously) claim it is not, using two main arguments. The first argument is based on the observation that Debian offers a set of pretty rare, if not unique, features among mainstream FOSS distributions. Those features consist of a mix of technical and "political" aspects: (1) a focus on package quality, with no distinction among first and second class packages; (2) a strong culture of software freedom, which refuses to offer non-free software (or firmware) by default to users and distribution developers (as parts of the infrastructure used to make Debian); (3) independence from commercial interests, with no single company or entity that could claim to babysit Debian; and (4) a decision making model based on a weighted sum of do-ocracy and democracy, which implies that by doing (rather than talking) everyone has a chance to have an impact on Debian. Considering all that and looking at the most popular FOSS distributions, one can easily identify Debian as one of the few remaining players who both care about Free Software and can be trusted in making choices not driven by profit. Mind you, I've nothing against companies in general and I'm very well aware that many FOSS companies carry a good deal of the burden of developing and promoting Free Software. Nonetheless, in days in which it is striking how quickly FOSS-friendly companies can become very much FOSS-unfriendly, I can't help putting my trust and efforts into community-driven projects, better if with no attached company label whatsoever. Furthermore, having distributions like Debian around can encourage other company-backed distributions to demand more and more independence and clarifications about the relationships between the community and the backing company. The second argument about the relevance of Debian is more pragmatic and rather straightforward: Debian is the root of a huge tree of derived-distribution (AKA "derivatives"), more than 120 according to popular distribution indexing sites. Each Debian derivative focuses its attention on, and directs its people power to, customizing Debian for a specific target and build entierly upon Debian work for all parts that do not need customization. That possibility is one key advantage of Free Software, after all. A well-known derivative example is Ubuntu, which is probably the most popular Debian derivative, enjoying a user base way larger than that of Debian itself. Ubuntu is heavily customized with respect to Debian and still had only about (at the time of Natty) 25% of packages which either differed from their Debian counterparts or that did not exist in Debian at all. Other Debian derivatives tend to be way less customized than that. Either way, if you are running a Debian derivative, chances are that you heavily depend on Debian and on its well-being. (Yes, it is so also if you didn't know about that, sorry.) Let's now fast-forward to the end of the talk, skipping my usual comments on how to keep the whole tree of Debian derivatives sustainable and beneficial for Free Software as a whole (i.e. by reducing as much as possible the viscosity of patch flow along the derivatives tree). Feedback People's reaction to such a provocative talk has been positive and we have enjoyed a fairly long Q&A session discussing the topics mentioned above as well as other Debian-related topics. A (commented) summary of the obtained feedback is reported below. Judging from the recurrent questions and suggestions I've received doing Debian talks in the past 8 months, I dare to say that LCA feedback is fairly representative of the feelings of many Debian users.

• Some people believe that Debian is too silent about its role with respect to derivatives. I agree: we should communicate clearly about this, as well as asking our derivatives to do the same. Initiatives such as the Derivatives Front Desk and, more recently, the Derivatives Census seem to go in the right direction.
• More generally, users seem to believe that we have the tendency to undersell what Debian has to offer and, in particular, the testing distribution (whose name is too scary in comparison to the unique balance it offers of up to date and tested software).
• There is a clear interest in rolling distributions among GNU/Linux users and Debian enthusiasts are no exception. Mentioning CUT seems to invariably whet the appetite of our users.
• On the other hand, there are also inquiries about the support period for Debian stable releases (currently about 3.5 years) and the possibility of having it extended. Once more, recent work in progress by the security team seems to be going in the right direction. As another potential underselling problem, not all users seem to be aware that Debian security support is on the whole archive, whereas other LTS offerings are not.
• Various users are enthusiast about the free firmware achievement for Squeeze and happy about the way we communicated about it. Questions about the purpose of other "free firmware" distributions with respect to Debian invariably arise, although it's not up to us to answer those.
• There is also interest in cross-distribution collaboration, probably triggered by a natural generalization of the invite of of collaborating across derivatives. I've been asked about Debian participation into the AppStream thingie and I've been happy to reiterate that it has been an important milestone in cross-distro collaboration.

Slides of the talk are available, while a video will eventually be posted at http://linuxconfau.blip.tv.

---

[1] Kudos to Francois Marier for suggesting the title. If the title doesn't ring a bell for you (it didn't for me in the beginning), you might want to check out the story of this ad. Update: minor rephrasing in the 4th paragraph

Debian Med Bioinformatics Sprint Last weekend, I was at the Debian Med Meeting in Travem nde near L beck, thanks to an invitation by Steffen M ller and Andreas Tille. It was a great opportunity to finally meet Steffen and some of the other bioinformatics people in Debian like Manuel Prinz face-to-face for the first time. Also, lots of upstream and related bioinformatics packagers from e.g. Biolinux were present as well, many of them from the UK. I discussed with and helped some people about Debian packaging. There is a big push to get Debian packages done and integrated in Debian and Ubuntu, but often enough people are not exactly sure what the requirements are and what needs to be done. Hopefully, the sprint was successful to clear things up and move forward. I also managed to finalize the initial Jmol packaging and uploaded it to Debian towards the end of the sprint. I plan to update the other bioinformatics related packages in debichem like pymol and openbabel as soon as squeeze is released. Overall, it was a great weekend, many thanks to NERC and Debian for making it possible, and to Steffen M ller for organizing it!

My FSF colleague Brett Smith and I will be making the case against software patents on a panel at the Churchill Club in Mountain View, CA, the evening of February 16th. Hope to see End Software Patents supporters in the audience! More information: Churchill Club Panel Discussion on Software Patents Free Software Foundation working together for free software

I often have ideas for little web sites, stuff I just get the urge to create for the fun of it. Some of them have done rather well, like langpop.com but even that doesn't make any money, and, sadly, as I age, that is becoming a more important factor in life. So I decided to try a little experiment. I was thinking some about "value" stocks, and fiddling around with Google's stock screener, and thought of the idea of a site that highlights underperforming stocks: http://underperformingstocks.com - so far so good - I went ahead and registered the domain, and put together the beginnings of a Rails application. At the same time though, I decided I have enough things to do in my evenings and weekends, so I decided that it might be interesting to start selling the site at the same time I'm building it. I'm not really sure how it will work out: perhaps people will see that there's not much there and not bid for it. Perhaps someone likes the idea behind it and is willing to buy on that. My idea, in any case, is to keep working on it as the auction progresses. As an additional twist, there are obviously a lot of features that could be added to the site, so I'll prioritize work on features suggested by users who have bid on the site. Here's the auction listing on Flippa.com: Edit: I'll also be posting updates to the twitter account I created for the project: http://twitter.com/#!/underpstocks

One of the things that everyone seems to do different is managing passwords. We haven t looked at that in quite some time, despite growth both of the company and the IT department. As I look to us moving some things to the cloud, and shifting offsite backups from carrying tapes to a bank to backups via the Internet, I m aware that the potential for mischief whether intentional or not is magnified. With cloud hosting, a person could, with the press of a button, wipe out the equivalent of racks of machines in a few seconds. With disk-based local and Internet-based offsite backups, the potential for malicious behavior may be magnified; someone could pretty quickly wipe out local and remote backups. Add to that the mysterious fact that many enterprise-targeted services allow only a single username/password for an account, and make no provision for ACLs to delegate permissions to others. Even Rackspace Cloud has this problem, as do their JungleDisk backup product, and many, many other offsite backup products. Amazon AWS seems to be the only real exception to this rule, and their ACL support is more than a little complicated. So one of the questions we will have to address is the balance of who has these passwords. Too many people and the probability of trouble, intentional or not, rises. Too few and productivity is harmed, and potentially also the ability to restore. (If only one person has the password, and that person is unavailable, company data may be as well.) The company does have some storage locations, including locked vaults and safe deposit boxes, that no IT people have access to. I am thinking that putting a record of passwords in those locations may be a good first step, as putting the passwords in the control of those that can t use them seems a reasonable step. But we ve been thinking of this as it pertains to our local systems as well. We have, for a number of years now, assigned a unique root password to every server. These passwords are then stored in a password-management tool, encrypted with a master password, and stored on a shared filesystem. Everyone in the department therefore can access every password. Many places where I worked used this scheme, or some variant of it. The general idea was that if root on one machine was compromised and the attacker got root s password, it would prevent the person from being able to just try that password on the other servers on the network and achieve a greater level of intrusion. However, the drawback is that we now have more servers than anyone can really remember the passwords for. So many people are just leaving the password tool running. Moreover, while the attack described above is still possible, these days I worry more about automated intrusion attempts that most likely won t try that attack vector. A couple of ways we could go may include using a single root password everywhere, or a small set of root passwords. Another option may be to not log in to root accounts at all possibly even disabling their password and requiring the use of user accounts plus sudo. This hasn t been practical to date. We don t want to make a dependency on LDAP from a bunch of machines just to be able to use root, and we haven t been using a tool such as puppet or cfengine to manage this stuff. Using such a tool is on our roadmap and could let us manage that approach more easily. But this approach has risks too. One is that if user accounts can get to root on many machines, then we re not really more secure than a standard root password. Second is that it makes it more difficult to detect and enforce password expiration and systematic password changes. I m curious what approaches other people are taking on this.

All translatable debconf templates for packages in squeeze are translated in Czech, German, French and Swedish. Two other language teams nearly reached that goal and failed to reach it because of flaws in communication with package maintainers:

• Russian is only missing 3 strings in debian-edu-config (they reached the package maintainers too late);
• Portuguese is missing 4 strings in udev (the package was uploaded way too late even though the translation was sitting there for weeks: next time, I'll NMU that package).

So, in my opinion, I will count SIX languages as reaching 100% in po-debconf. Another great effort is currently going on with the Squeeze Release Notes translation, where 8 languages are very likely to be complete (http://www.debian.org/releases/testing/statistics.html) and a strong last-minute effort by a motivated Danish team could likely add one. And, of course, you all know that Debian Installer supports 70 languages with 57 of them with a full translation.

I m switching from WordPress to a virtual private server. I m playing with a Gandi.net VPS. So far, I m happy with their domain registration service. Also, they offer some discounts for Debian people. Btw, I still have a promo code for a one month free VPS share which I m allowed to give away. For my new website (same old URL) I m using PyBlosxom over Lighttpd in a Debian GNU/Linux system. I want to keep things simple by git-pushing plain text files for all html content. For the blog system I ve just written a plugin which gives PyBlosxom the (very nice!) txt2tags formatter (source: t2t.py). There re still issues to fix but it s working quite well. So, thanks WordPress for all the fish. This is probably my last post here. (although I m keeping the current account active for comments)

A few days ago, I closed two bugs in the #17xxx range and I found that pretty cool already. But a few hours ago, I closed #6734, which is the oldest bug I ever closed! It took more than 14 years for somebody to reply, oops Next one to take care of, #2297. Apparently, it s so old that the initial bug report was lost at some point.

I love Amarok, since the beginning. But I have had issues since I moved from awesome (and didn t knew it was coincidence) with my multimedia keys. Today I discovered a script called Gnome Multimedia Keys 2 for Amarok2 and now I got it working again, after trying with Banshee, Rhytmbox, Songbird, Exaile I went back to Amarok :D

Managed to grab a few shots of my brother's Pug in the garden in one of the rare moments it stood still.

As of version 0.17, gitpkg ships with a hook called quilt-patches-deb-export-hook. This can be used to export patches from git at the time of creating the source package. This is controlled by a file debian/source/git-patches. Each line contains a range suitable for passing to git-format-patch(1). The variables UPSTREAM_VERSION and DEB_VERSION are replaced with values taken from debian/changelog. Note that $UPSTREAM_VERSION is the first part of $DEB_VERSION An example is

 upstream/$UPSTREAM_VERSION..patches/$DEB_VERSION
 upstream/$UPSTREAM_VERSION..embedded-libs/$DEB_VERSION

This tells gitpkg to export the given two ranges of commits to debian/patches while generating the source package. Each commit becomes a patch in debian/patches, with names generated from the commit messages. In this example, we get 5 patches from the two ranges.

 0001-expand-pattern-in-no-java-rule.patch
 0002-fix-dd_free_global_constants.patch
 0003-Backported-patch-for-CPlusPlus-name-mangling-guesser.patch
 0004-Use-system-copy-of-nauty-in-apps-graph.patch
 0005-Comment-out-jreality-installation.patch

Thanks to the wonders of 3.0 (quilt) packages, these are applied when the source package is unpacked. Caveats.

• Current lintian complains bitterly about debian/source/git-patches. This should be fixed with the next upload.
• It's a bit dangerous if you checkout such package from git, don't read any of the documentation, and build with debuild or something similar, since you won't get the patches applied. There is a proposed check that catches most of such booboos. You could also cause the build to fail if the same error is detected; this a matter of personal taste I guess.

I have to cheat a little bit in fourth week as the picture is actually from last Sunday. I simply did not have time to take my camera out. The photo was taken at visit Glassworks Novosad a syn at Harrachov.

Filed under: English Photography 0 comments Flattr this!

Apparently I forgot to put my initial call for release parties on planet.debian.org. Sorry, so much things to do, so little time... As Debian Squeeze will be released next weekend, it's a good time to start preparing a release party in your city. Be it in a pub, a pizzeria, or your living room: Organizing and hosting a release party is an ideal opportunity to meet, exchange GPG fingerprints, exchange knowledge and of course be merry and celebrate :) If there's going to be an event in your city, please add it to our wiki page so others can find it and join you :) Oh, and the publicity got the idea to do some live commenting of the release process via Debian's official identi.ca account. Might become interesting to watch that, too, as we also plan to fill boring waiting parts with funny and interesting facts :) Oh, and if you should know / or would be interested in an interesting facts (e.g. the the 150'000 closed bugs since Lenny got released please contact us, as we are still preparing them ;)