As I type this, it's just passed midnight. I'm in the back of a BMW somewhere in east Germany , and the Debian UK convoy is doing 110 mph on the autobahn, twenty hours into a twenty-five hour first leg of our trip to Banja Lunka. This all started out so sanely with a 3 am departure to catch the 6 am ferry at Dover. Followed by a couple of hours leisurely breakfast onboard. First hint that yes, this is a road trip in which things will go wrong was a minor bumper denting of one of the convoy's cars by a stray landrover during the ferry trip, but it didn't really phase us. On to Cologne, for a very nice lunch and to pick up another person. But we didn't anticipate how brutal the next leg to Gratz would be. Nor did we count on apparently half of Germany and the Netherlands getting out their campers and heading east this Friday. Spent multiple hours stop-and-go, and many more in constant traffic. Finally it opened out, so we can follow the night speed limit. And while we started out horsing around on the radio, we've developed some real comms discipline by now to keep the convoy together. Also people seem to be amazingly keeping rested while not driving. To add to the sleep debt to me, I flew in the day before, but I actually feel caught up now. Still I've not been driving at all due to mislaid license and general inability to safely drive a right side drive stick shift at 100 mph at night. Our 7 drivers are doing an amazing job. Update: Arrived safely in Gratz at 4 am. Austria tantilized with 30+ miles of tunnels thru the alps, but I've not seen an alp yet.

---

PS, you'll never appreciate a stinky, free bathroom until you're in a country where all the antiseptic bathrooms cost money and hoards of vacationers are doing the logical thing next to service stations.

average sprint speed: 1 sprint/month I've proposed a DebConf11 BoF on Debian sprints and, more generally, on how we have been using Debian money in the past 1.3 years. As part of the BoF preparation, I've taken the time to review the last 16 months of sprints and check how the Debian Sprint Program which we've recently streamlined and "marketed" quite a bit is going. In particular, I've finally done the homework of preparing the big table of sprints and their costs, in order to evaluate how sustainable the sprint program is. Without further ado, here is the table:

Debian sprints held from April 2010 to June 2011

No	Sprint	When (month)	Where	Attendees	Debian cost (EUR)
1	groupware (report)	04/2010	de	4	240
2	FAI (report)	06/2010	de	7	570
	(DebConf10)	08/2010	us
3	ftpmaster (report)	09/2010	de	3	350
4	DSA (report)	09/2010	de	3	400
5	release team (report)	10/2010	fr	6	0
6	kernel team (report)	10/2010	fr	3	120
7	www team	12/2010	at	5	1430
8	debian med	01/2011	de	25	460
9	security team	01/2011	de	7	1000
10	emdebian	02/2011	uk	17	0
11	ftpmaster	03/2011	de	5	2000
12	groupware	04/2011	de	6	300
13	alioth	05/2011	uk	4	500
14	debian edu	06/2011	de	9	760
15	release team	06/2011	be	5	1640
	(DebConf11)	07/2010	ba
Total	15 sprints	16 months			9770

To better understand the table, several comments are in order:

• numbers are approximate in various ways. In particular, 2010 costs predate a protocol I've agreed upon with the Debian auditors to do proper accounting, hence it is possible that some costs are slightly overestimated
• costs are Debian's costs and do not include reimbursements for non-Debian people that might have attended the sprint. This also explains why some sprints have been at 0 cost: they have been entirely sponsored by other entities interested in supporting Debian, such as companies or institutions.
• where needed, costs have been normalized to Euro
• we have streamlined the sprint process around October 2010 (you can find the underlying rationales in an old RFC). Sprints happened before that data had a different way of being announced and of reporting back to the project.
• the above data are not detailed enough to properly estimate per-person costs, as we lack a breakdown of Debian vs non-Debian attendees
• no costs for DebConf-s are included, as they have their own budgets which aims to be amortized 0 cost in the long run

Please note that the purpose of the table is not to be precise and transparent about Debian finances and how we use them. That is a (very!) worthwhile goal and I do think Debian should do much better in informing its community about how donated money are used to further Debian goals. But that is a broader topic on which the auditors are working; it is not up to me to discuss it here. If you are interested in that topic though, you might want to follow tbm's BoF at DebConf11. The purpose of the table is rather to find out some general figures about Debian sprints held in the recent past:

• we have had a total of 15 sprints in 16 months (about 1 sprint/month)
• we have spent about 10'000 EUR for sprints, for an average per-sprint cost of about 650 EUR
• all sprints have been held in Europe
  (given DD geographical distribution, I find quite surprising that no group of US-based Debian hackers have asked for sprint sponsoring)
• about half of the sprints have been held in Germany
  (probably thanks to DD-density there and also to the welcoming attitude of friendly venues such as the Linux Hotel)
• the variance of per-person costs is high: there are very cheap sprints (e.g. when people travel within Europe by train and stay at friends') and quite expensive sprints (e.g. when one or more of the participant needs to be flown oversea which has happened only once, up to now)

I'm personally quite happy about those figures. Enabling volunteer developers to meet and hack together in person is possibly the most valuable way of using donated money. Having 1 sprint/month is not bad, but in a project the size of Debian is quite possibly a minimum. Doing more than that is highly desirable. It is also financially sustainable, especially if we will be able to show by actually having more sprints and being transparent about them that we can put into good use donated money. Another, more subtle, aspect of sustainability is that related to sprint management. Processing sprint requests and ensuring that transparency guidelines are actually followed by the organizers is still quite some work. I've been mostly doing that myself up to now, which is all fine and well, but does not necessarily scale. Other organizations (such as KDE e.V.) have realized that to the point of having hired people specifically to manage sprints in an otherwise volunteer community. In Debian we are quite keen of maintaining the project running on a volunteer basis. At the same time I feel we should have more room for scalability in the number of sprints we could run. So if you are looking for a management task to help Debian with, think about becoming, err, "sprint master", and contact me. If otherwise you want to focus on Debian hacking, what are you waiting for? Check the guidelines and propose your sprint! To know more about sprints, Debian money, and how you could help with all that, be sure not to miss the Sprint and money BoF.

There was an interesting issue in D-Bus, related to unicast vs broadcast signals, which led [edit: typo] to a small change in specs and which might be of some interest for D-Bus developers.

Unicast signals are not widely known and probably even less used, but they are possible.
They are useful, for instance, when you need to trigger an action from a single client, among your listeners.

Until some days ago, when a unicast signal was emitted, it was actually received by everyone listening to the signal's interface (unless a strict rule was added, unusual), waking up a number of processes which actually weren't interested in the signal.
Collateral effect, waking up cost apart: those processes might actually consider the signal as they were the actual recipient and take some action upon it. Bad.

Typical rule having this problem is "sender="org.foo,interface=org.bar".
Imagine several clients using this rule to listen to org.foo, but org.foo wanting to send a signal to :1.23 only.
Specifying destination=:1.23 for the signal object didn't really work since no dest=val was specified in the rule, allowing any destination actually matching it and all the listeners to be woken up anyway.

The problem with this situation was fixing the bad behaviour without filter out eavesdroppers, which actually wanted to receive the message even if not for them.

The solution is a sort of "eavesdrop opt-in", as Thiago proposed to add a keyword to DBusMatchRule, "eavesdrop=true false" which defaults to false and with which the listener declares that it really wants to eavesdrop, enabling it to receive messages (including signals) not meant for it (AKA eavesdropping).
Otherwise any message (again, including signals) with a specified destination won't match a filter with no or different destination. Also a rule with a specific destination won't match broadcast messages.


In other words, by default a match rule filter will match only broadcast messages or the ones specifically for you, unless you declare your very nature of eavesdropper by adding "eavesdrop=true" to your filter rule.

This is a behavioural change and consequently means a small amend to the D-Bus spec for 1.5.x.

It also means that if you maintain some code which acts as an eavesdropper, you should fix the code adding "eavesdrop=true" to your filter.
Note that it's only for 1.5.x branch; adding the "eavesdrop" keyword to a filter sent to a 1.4.x bus will fail as the keyword is not recognized.
An example on how to deal with this change keeping compatibility toward 1.4.x (stable branch) and 1.5.x (devel branch) at the same time is shown by this bustle fix. It checks for the feature presence and prepends the keyword if supported.

... or TDDD and DEP8 context As a nice byproduct of the huge "rolling" discussion we had back in April/May, various people have brainstormed about applying Test-Driven Development (TDD) techniques to Debian development. Here is a brief summary of some opinions on the matter:

• a seminal conversation on identi.ca
• a couple of blog posts by Lars, discussing the general problem of how to use TDD in distribution development and to a lesser extent its instantiation to Debian
• a separate post by Daniel stressing the specific TDD advantage of increasing the confidence of maintainers in making far reaching changes

... and hey, they've also coined the cool TDDD acronym, which I hereby took the freedom to re-target to Test-Driven Development in Debian. Having a cool acronym, we are already half-way to actually having the process up and running *g*. more testing I believe Debian needs more testing and I've been advocating for that since quite a while e.g. at DebConf10, as one of the main goals we should pursue in the near future. Of course advocating alone is not enough in Debian to make things happen and that is probably why this goal has been (thus far) less successful that others we have put forward, such as welcoming non-packaging contributors as Debian Project members. There are important reasons for increasing testing in Debian. quality assurance Quality Assurance has always been, and still is, one of the distinctive traits of Debian. I often say that Debian has a widespread culture of technical excellence and that is visible in several places: the Debian Policy process, lintian, piuparts, periodic full archive rebuilds, the EDOS/Mancoosi QA tools, the cultural fact that maintainers tend to know a lot about the software they're packaging rather than only about packaging, the we release when it's ready mantra, etc. But caring about quality is not a boolean, it's rather something that should be continuously cherished, refining quality requirements over time. By simply maintaining the status quo in its QA tools and processes, Debian won't remain for long a distribution who could claim to care about package quality. Others will catch up and are in fact already doing that. In particular, we surely have room for improvements in our quality tools and processes for:

• Build time package testing. Several packages run their build-time test suites during package build. This aspect is somewhat supported by the Debian policy; we also do a best effort attempt to run build-time test suites via debhelper (starting from version 7). At the same time we could probably campaign more to encourage maintainers to look for build-time test suites which do not follow common Makefile target naming or, fwiw, which don't rely on make at all. TodoList.add("investigate and possibly file bug report against policy to encourage maintainers to run build-time test suites")
TodoList.add("investigate and possibly file bug report against lintian to spot the presence of [non-invoked] build-time test suites")
• Runtime package testing (AKA "as-installed package testing"). Some kinds of test-suites are difficult to run at build-time (e.g. complex applications that don't offer easy way to re-configure on the fly their filesystem paths) and some others are plainly impossible to run without having the packages to be tested properly setup (e.g. running services that are accessible only through the network) or an isolated, throw-away testbed (e.g. bootloaders, kernels, etc.). TTBOMK this kind of testing is not currently in use neither in Debian nor, indirectly, in any of its derivatives. autopkgtest (AKA DEP8) is a step in this direction; I will get back to it later on in this post.
• Integration testing. When applied in the context of distributions, integration testing is about testing package combinations, task (as in tasksel) combinations, basic system functionalities, automated installations, etc. This is the aspect that Lars has discussed the most (and in which he seems to be interested the most) so I don't feel like adding much. Still, it's interesting to note that on this front Debian has an important potential to exploit. The large base of its developers and the fact that the average Debian user is technical savvy mean that we can potentially collect a lot of test cases. It's "just" (with well-deserved double quotes) a matter of deciding a standard interface for test case submissions and developing a most likely virtualized test runner. At that point a continuous integration service that periodically run and publishes results can be setup independently from the rest of the Debian infrastructure and offered to interested eyes, such as Release Team's. Any taker?
• Automated code analysis and in particular automated bug finding is something which is becoming more and more common and finally, after decades of research viable. Successful proprietary tools and businesses are aplenty (a nice and very fun read on the subject is the story of Coverity), as well as FOSS solutions. For instance, the Linux kernel is routinely using Coccinelle to automatically find bugs and even produce the corresponding patches. Add to the above the fact that Debian is one of the largest software collection in existence (and quite probably the largest collection of Free software in existence) and is upstream of the packaging of that software for the most part. That turns Debian into a very peculiar platform for large scale automated code analyses. Not that we can aim at fixing all the bugs we are going to find, or even hope to tame all the false positives we are going to find. But we can offer an important service to the whole ecosystem of Free software and use it to pinpoint important class of bugs from a distribution point of view, such as nasty security bugs (as long as they can be automatically found ). DACA is a very good step in the right direction, even though it is still in its infancy.

reducing inertia Inertia is a recurring topic among Debian lovers (and haters). It is often argued how difficult it is to make changes in Debian, both small and large, due to several (alleged) hindrances such as the size of the archive, the number of ports, the number of maintainers that should agree before proceeding with a cross-package change, etc. It's undeniable that the more code/ports/diversity you have, the more difficult is to apply "global" changes. But at least for what concerns the archive size, I believe that for the most part it's just FUD: simply debunking the self-inflicted culture about how "dangerous" doing NMUs is might go and has already gone, imho a long way to fight inertia. Adding per-package and integration tests will make us go another long way in reducing inertia when it comes to performing archive-wide changes. Indeed if a package you are not entirely familiar with has extensive test suites, and if they still pass after your changes, you can be more confident in your changes. The barrier to contribution, possibly via NMU, gets reduced as a result. And if your change will turn out to be bad but still not spot by the test suites, then you can NMU (or otherwise contribute) again to extend the test suite and make the life easier for future contributors to that package. It smells a lot like an useful virtuous cycle to me. autopkgtest / DEP8 how you can help Of all the above, the topic that intrigues me the most is as-installed package testing. Work on that front has been started a few years ago by Ian Jackson when he was working for Canonical. The status quo is embodied by the autopkgtest package. At present, the package contains of various tools and the following two specs:

1. README.package-tests provides a standard format to declare per-package tests using the new debian/tests/control file. Tests come as executable files which will be run by the adt-run tool in a testbed where the package(s) to be tested is already installed. This part of the specs has been reified as DEP8 which I'm (supposedly) co-driving with Iustin Pop and Ian (for well-deserved credits).
2. README.virtualisation-sever describes the interface among the test runner and the testbed. A nice separation is provided among the runner and the testbed, enabling different testbed environments with a varying degree of isolation: you can have a "null" testbed which runs tests on your real machines (needless to say, this is highly discouraged, but is provided by the adt-virt-null tool), a chroot testbed (adt-chroot), or a XEN/LVM based testbed (adt-virt-xenlvm).

The specs allow for several runtime testing scenarios and look quite flexible. The tools on the other hand suffer a bit of bitrot, which is unsurprisingly given they haven't been used much for several years. At the very minimum the following Python development tasks are in need of some love:

• The usage of python-apt needs to be ported to recent API, as several used methods and attributes are now gone.
• Porting from dchroot to schroot is needed for the adt-virt-chroot backend.
• A kvm backend for the test runner would be nice.

If you are both interested in TDDD and grok Python, the above and many others tasks might whet your appetite. If this is the case don't hesitate to contact me, I'll be happy to provide some guidance.

---

Note: this post is the basis for the TDDD BoF that I will co-host with Tom Marble at DebConf11. If you plan to come, we will appreciate your thoughts on this matter as well as your help in getting the autopkgtest toolchain up and running again.

Martin Michlmayr is a Debian developer since 2000 and I share quite a few things with him, starting with his age and involvement in the quality assurance team. He managed to be elected Debian Project Leader in 2003 and 2004. He s no longer as active as he used to be but his input is always very valuable and he continues to do very interesting things in particular concerning the support of NAS devices. Read on for the details. Raphael: Who are you? Martin: I m Martin Michlmayr. I m 32, originally from Austria, and currently living in the UK. I ve contributed to various free software projects over the years but Debian is without doubt the one I m most passionate about. I joined Debian in 2000 when I was a student. I worked on Debian more or less full time for a few years while I was pretending to study. Later I started a PhD to do research about quality and management aspects of volunteer free software projects. I investigated the release process in several free software projects, in particular looking at time-based releases. After finishing my PhD in 2007, I joined Hewlett-Packard. I m part of HP s Open Source Program Office and work on various free software and open source activities, both internally and within the community. Raphael: How did you start contributing to Debian? Martin: I first used Debian in the days of 0.93R6, some time around the end of 1995. The 0.93R6 release was still based on a.out but I needed an ELF-based system for some application, so I moved to Slackware. I then quickly moved to Red Hat Linux where I stayed for several years. I rediscovered Debian in 2000 and quickly decided to join the project. I cannot recall how I rediscovered Debian but when I did, it was clear to me that Debian was the ideal project for me: I could identify with its philosophy, I liked the volunteer nature of the project, and I found the size and diversity of Debian interesting since a large project offers a lot of different challenges and opportunities. I remember how many new things there were to learn and back then the documentation and other resources for new contributors were nowhere as good as they are today. My application manager, Julian Gilbey, was a great help he was incredibly friendly and passionate about Debian. I also remember meeting up with Peter Palfrader (weasel) for key signing when we were both in the New Maintainer queue. I was incredibly lucky with my New Maintainer process and soon became an official Debian Developer. Because there was a shortage of application managers, my first major contribution in Debian was to become an application manager myself and help other people join the project. Debian is a large project with a long history and a rich culture, so new contributors should expect that it will take some time to become familiar with everything. Fortunately, there are many resources, such as documentation and the debian-mentors list, for new contributors. Another great way to become familiar with the way things are done in Debian is to subscribe to various Debian mailing lists and ideally to read some mailing list archives. It s also a great idea to attend the Debian Conference or other conferences since meeting people in real life is a great way to integrate. I remember attending Debian Conference 1 in Bordeaux where I gave my first public talk. Finally, new contributors should find an area where they can make a unique contribution. Most people in Debian maintain packages but there are so many other ways to contribute. For example, most of my contributions were not technical but were about coordination and other organizational activities. Raphael: What s your biggest achievement within Debian? Martin: I m particularly proud of a number of achievements:

• New Maintainer: I helped a lot of people join Debian. It s great to help someone join the project and then see how they contribute. Of course, some people join Debian and then quickly become inactive or retire you never know in advance how it will work out. But I had the pleasure to help some truly outstanding contributors to join Debian.
• Quality Assurance: I helped improve QA processes within Debian. In particular, I realized a few years ago that a lot of packages had maintainers who were inactive and that nobody did anything about it. I started to write to those maintainers to see what could be done. It s hard because you don t know the circumstance of someone they may be inactive because of an illness or for other good reasons so you have to be friendly, but yet persistent. Fortunately, most maintainers I contacted were truly inactive and so they couldn t complain when I took their packages away.
• DPL: I acted as the Debian Project Leader for two years. I m particularly proud of this because Debian is a great project and it was an honour to represent it. I performed important organizational and coordination tasks. I also traveled to a lot of conferences and had the pleasure to meet many Debian Developers as well as users of Debian. It s very motivating to meet users and to hear how they use Debian and how we can further improve it.
• Debian on NAS: Debian is without the doubt the Linux distro with the best support for NAS (Network Attached Storage) devices. I was always impressed by what the OpenWRT folks have done to support wireless routers and wanted to do something similar for Debian. Unfortunately, wireless routers just don t have enough storage for a full distro. But then NAS devices came along and they obviously have enough space since they are meant for storage.

Raphael: Speaking about NAS devices: what exactly are you doing on this topic and how can people help? Martin: There are plenty of instructions on the Internet to install Linux distributions on NAS or various embedded devices by connecting a serial console and then typing in hundreds of commands. What I found is that such instructions significantly limit the user base because they are way too complicated for most users. There are just too many steps that can go wrong. So instead, in Debian, we provide a solution that just works: usually, you download a firmware image for your NAS device from Debian and when you upgrade you get the Debian installer. You connect to the installer via SSH and perform a normal installation. The installer knows about the device and will prepare everything for you automatically for example, it knows if the device has requirements for the partition layout and it will install the kernel where the device expects to find it; unfortunately, NAS devices are not like PCs, so the requirements are different for almost every device and therefore you need special code to support a new device. Finally, there are detailed installation guides and we provide help on our mailing lists. There are a number of technical areas for improvement. The installation could be made even easier, and it would be nice to support new platforms and devices. A bigger problem is that while we ve implemented a great solution for NAS devices, we haven t really extended this work to support other classes of devices. For example, tablets and mobile phones are getting incredibly popular and we don t have a compelling solution for such devices, mostly because of the lack of an appropriate GUI. Raphael: What are your plans for Debian Wheezy? Martin: I ve recently been asked by Stefano Zacchiroli, our current Debian Project Leader, to coordinate the care-taking of Debian finances. Debian, as a volunteer project, relies on donations and in-kind gifts (e.g. hardware) to maintain its infrastructure and to support various development efforts, such as funding sprints and other developer gatherings. Debian s money and other assets are held by affiliate organizations around the world. My responsibility will be to keep track of money and other assets (e.g. hardware and trademarks), work with the DPL to establish procedures related to the use of Debian s assets, and make sure that the procedures are followed. Finally, we want to publish public statements so our donors know how we use their donations to further improve Debian. I just started working on this and this will be my main activity in Debian in the coming months. Raphael: Speaking of money, I plan to run a fundraising to get the Debian book I wrote with Roland Mas translated (cf. http://debian-handbook.info). Is this something Debian should support? Martin: First of all, I should make it clear that I don t decide how Debian spends its money. This is up to the DPL to decide together with the project at a whole. I ll just make sure that procedures are followed and expenses tracked and reported properly. Having said that, in my opinion, it s unlikely that Debian as a project will fund this effort. It would be inconsistent with the position of the project not to fund work directly (only some related expenses, such as travel costs to allow Debian teams to organize face-to-face meetings). Whether Debian should support the fundraising effort by helping to promote it is another question and that s probably not as clear cut. It looks like a worthwhile effort, but on the other hand it would be unfair for authors of other Debian books for Debian to put its weight behind one and there are many other efforts that are worth promoting if you promote one, where do you stop? So while it sounds worthwhile, it s probably better for Debian to stay out of it. But somehow related to this, I sometimes worry about the fact that there are so few paid opportunities around Debian. If you contribute to the Linux kernel for a while, you have an excellent chance to get hired by someone and to work on the kernel full time. The kernel may be an extreme example but there are a lot of projects that have more paid opportunities than Debian, e.g. Mono, GNOME, OpenOffice/LibreOffice and KDE. Obviously, there are some Debian Developers who can spend some time on Debian as part of their job. I know that some Canonical employees contribute to Debian, that support companies like credativ improve Debian as part of their work, and that system administrators fix bugs or package new software as they deploy Debian. But I think this is a minority of contributors and even they don t work full time on Debian. Instead what I see is that a lot of people leave university, get a job and then no longer have time for Debian or people start a family and no longer have time. I can take myself as an example since I don t have nearly as much time as I did in the past when I was a student. I guess there are different ways to deal with this problem one would be to create more paid opportunities around Debian outside the project, another one might be to make it easier for new volunteers to join the project. I don t have the answers to these questions but it s something I wonder about, and I also wonder whether pure volunteer projects can still keep up with projects with a lot of full time contributors. Raphael: What motivates you to continue to contribute year after year? Martin: Debian is a great project with a great mission, goals and people. I contribute to make Debian a better solution and to promote the free software philosophy. Finally, the community around Debian provides a lot of motivation. It s amazing how much I ve learned about other cultures because of my involvement in Debian and how many friends I ve made over the years all around the world. Raphael: Do you have wishes for Debian Wheezy? Martin: Not really. I m pretty happy with the way things are going at the moment. We have made a lot of organizational changes in the last few years from which the project has greatly benefited. I m particularly pleased about the plans to adopt a time-based freeze. Raphael: Is there someone in Debian that you admire for their contributions? Martin: There are many people I admire greatly. I d like to mention Joey Hess because he s a great example to follow. He doesn t get involved in politics, is easy to work with and does great technical work. In fact, he has made not one but several contributions that have completely changed Debian (debconf, debhelper, and debian-installer). Furthermore, Debian has a lot of contributors who have done great work over the years but who are not very vocal about it. People like Colin Watson or Peter Palfrader. Debian has many unique contributors and the list of people I admire is much longer than the few people I just mentioned.

---

Thank you to Martin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. He raised some interesting questions. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Before arriving to DebConf11, I arranged my flights so that I had a day and a night in Paris as I have not been there before. So after checking out of my work apartment in Tampere, going to work there with all the things from that apartment, then flying back to Riga, going to a midnight screening of the last Potter movie and finally getting back home around 2am, I quickly checked that I have everything needed for the conference and went off to sleep only to wake up at 8am again, pack everything (into a single carry-on bag, after a year of experience travelling by air weekly and watching Up in the Air twice) and be off to the plain to Paris. The CDG airport is quite huge, even compared to something like JFK it feels bigger and more concrete. And yet so dark and lacking interesting features that the only photo I got from it was this I then used the B line train to get to my hotel(9.1 ), drop my stuff there and another metro ticket (1.7 ) to go to Arc de Triomphe (M tro Charles de Gaulle-Etoile), went up there and walked the length of the Champs-Elys es right up to the Louvre. Then I walked to the river, crossed it to a small island to see the Notre Dame and then went back following the other bank of the river Seine seing both some more normal non-touristy streets of central Paris and also some other magnificent buildings, like Les Invalides and ending up at the Eifel tower. It was a rather easy walk that was only spoiled by some rain in the end so I did not get to take some night photos of the Eiffel tower as I wanted. But the experience still was breathtaking. The scale of the buildings was impressive. The pervasive gold-gilded decorations do expand on the splendour and the same time the full access to all the previously-royal places brings them down to people. The city looks well built and the planning mostly makes sense, especially if you are on foot. Car drivers might have a different opinion about it considering the maze of roads and traffic circles and underpasses I saw in central Paris. It is often said that Riga is a mini-Paris. Mostly, that is said in Riga. But walking the back streets of Paris I can see where that comes from the architecture, the street design, the small cafes and some cobblestone roads and some historical buildings with a few modern building thrown into the mix, and a tower too. Visually Riga does look like Paris a lot, but for the feeling, I still think that Riga feels more like Berlin with its mix of eastern and western Europe. I had one incident when some girl in front of Louvre started to ask me to sign something, gesturing to show that she was mute, it looked like a donation racket, but I did not get to find it out in detail as a swift security guard appeared and started running for the girl, who immediately took off running along with several friends. I guess the guards know them very well. On a more positive note, in one of many confetterie shops I noticed the macaron sweets that my friend advertised loudly some time ago, so I decided to buy and try some. They cost 7 for a box of 6. The taste was very, very sweet. Basically it tastes like froffed up and then frozen sugar made into cookie form with a cream layer between two cookies. So basically it is like an Oreo cookie, but much, much, much more tender, airy and sweet. The two of the 6 cookies were partly crushed while I tenderly carried them for 5 minutes in their box while searching for a place to sit down and eat them. After that I also had a proper dinner in a restaurant that was not too near the touristy paths, but still it was a bit lacking. The starter was quite nice I mean it is hard to screw up cutting off a piece of foie gras (basically a piece of liver paste with a layer of extra geese fat), but the main dish was disappointing I ordered a medium rare steak. First of all it came with a side of fries, that in itself was an insult to Paris, baked potatoes would have fit much better with this dish. And despite the main part of the steak being very nicely done to medium rare, the cut was done badly and the edges of the steak had sinew that was too chewy to eat or even cut normally. Other interesting things I liked about Paris:
* high street shops of fashion labels and car manufacturers, that showed off the concept cars and also sold small branded accessories, such as Mercedes Benz key chains * Statues some made of stone, some of iron, some covered in gold, everywhere and made with great quality * Bicycle rentals, I mostly saw the locals using them * Segway tourists * And countless classic postcard shots of very recognizable architecture The Eiffel tower was immensely impressive. It towers over everything around, especially because there simply is nothing high enough around it. It would not have been so impressive in the middle of New York, for example. The age and openness of the construction makes you really feel the massiveness of this marvel of functional architecture. But in the end Paris also looks like a great city to just kick back and relax in P.S. I am amazed that when I put a link to a Flickr image (such as http://www.flickr.com/photos/aigarius/5950187165/in/set-72157627230456160 in a separate paragraph in my WordPress article text, something along the way translates them into proper linked images with a reasonable size. Progress is amazing.

At the Copenhagen airport, Mika and I found the quiet room. It was a soft, well lit, room designed for prayer and reflection. During the hour I was in it, the only other visitor was a child cracking open the doorway to peer in. The room had a guest book with hundreds of messages left by other travelers over the last couple years. People praised the airport administrators for providing the room, made suggestions, and complained about the room, the airport, and the country's shortcomings. They talked about themselves, their travels, their happiness and unhappiness with departing or returning home, and their thoughts about the world. I spend a lot of time in airports but only rarely speak to my fellow travelers. It's amazing how little I know about the thousands of people waiting in line with me, sitting near me on the plane, and sharing in the long, lonely, and often stressful experience of moving between countries and continents. The guest book provided a rare window into these people in what is normally the anonymous and depersonalized non-place of airports. In the quiet room, I could -- for the first time -- hear some of these fellow travelers speak.

Some weeks ago I noticed that one of my backup servers was not removing the old backup generations it was making. It had over 18 months worth of daily backups, done with rsync and "cp -al". This is not the world's greatest backup system, but that's entirely irrelevant for this rant. The cron job that would do that did not exist: I had forgotten to enable it. So I ran it by hand. Then fixed it, when I noticed it was buggy, and didn't remove any old generations prior to 2010. After that I removed years-old backups of machines that haven't existed for years. Disk usage:

       Size  Used Avail Use% 
before 5.4T  2.6T  2.6T  51% 
after  5.4T  892G  4.3T  18% 

Inodes:

          Inodes    IUsed     IFree IUse%
before 732577792 77645915 654931877   11%
after  732577792 16871789 715706003    3%

That's about 61 million files removed, over the course of three weeks, of which the machine was down due to crashes for about one week. It should not take two weeks to copy a couple of terabytes (it's less than two megabytes per second). It should definitely not take two weeks to delete it. Almost all the time it was up, it was removing files. There were a couple of times when it finished one run and was idle until I woke up and started the next run. Say a day in total. Why is "sudo rm -rf" on a large directory tree, or set of large directory trees, so slow? I suspect part of the problem is that the system call API is beautiful, but simplistic: you need to call unlink or rmdir on every file separately, and that means doing an inode lookup separately for each file. Having a system call to delete everything in a directory would have a chance of removing things more efficiently, I suspect. However, since I've not done any profiling, nor even analyzed the relevant source code in the kernel, I might be entirely wrong. I wonder if anyone else needs to remove large directory trees frequently? I do that a lot, because of my backup software development hobby. But I may be in a unique position, and nobody else would benefit from fast removal. (I'll note that my backup server is using ext3, and that ext4 is much faster at removing files, particularly large files, but it's still not fast enough.)

As the local geek I get all sorts of (Linux) questions asked, like "How can you delete the nth line with Sed?" or "Is there a way to search for the following in a file?" (the latter being a request to construct a regular expression for grep). And while I'm pretty sure, you can find answers for such questions quickly with $SEARCH_ENGINE I find myself generally typing the answer into the IM session. This, and just seeing Bernd's post about Vim on Planet Debian, prompted me to start a little, irregular series of posts, to which I can point people, whenever I get asked such questions. I start this off with a tip for Vim, a very powerful text editor. The problem is simple: you get (source code) files with trailing whitespaces (sometimes accumulated in "empty" lines). This makes diffing (and merging) difficult. Thus the question is: how do I prevent that from happening? How do I notice, that I have whitespaces at the end of a line? The solution consists of two lines in your .vimrc:

:highlight TrailWhitespace ctermbg=red guibg=red
:match TrailWhitespace /\s\+$\  \+\ze\t/

If you just want this functionality if syntax highlighting is also active, then you should use

:autocmd Syntax * syn match TrailWhitespace /\s\+$\  \+\ze\t/

instead of the :match line. The regular expression used in both cases matches trailing whitespaces and whitespaces in front of tabs. Of course there are several other options on how to do this or what you might want to highlight, but that would be beyond the scope of this little post.

Sometimes projects with a long history of committers tend to collect various styles of indentation. Unfortunately not for all programming languages exist specialized tools like indent for C/C++, so we need to find a different way to mass-indent files properly. Using vim is one of them. First you need to create a file (let's call it /tmp/indent.vim) including all the vim commands you want to run on your code. The following piece is a good start:

gg=G
:x!

Now run vim on your source code files, using the created vim script file. The following example reindents all .php files in the current folder and subfolders

find . -name '*.php' -exec vim -s /tmp/indent.vim   \;

If you don't like the result it might be that the indentation settings in you .vimrc don't suit your needs. Of course you are able to add other fancy vim commands to modify your files - like adding or modifying copyright headers.

Okay, so the story continues: Joe Brockmeier has posted a rebuttal to Nina Paley's post that I commented on earlier today. Basically, Joe says that Culture is not the same things as Software, and gives a lot of arguments as to why this would be true. But I can't agree with him. Let's see why. His first argument is "One of these things is not like the other". As in,

But it's far more reasonable and sensible to discuss Perl scripts and software written in assembler embedded on a chip together, and the rights that they come with, than to try to talk about rights to modify sculpture and essays.

I don't see how one could combine a perl script with an embedded assembler program, except perhaps over a network, or by using exec() two cases in which the FSF would consider that they are not even derivatives anymore, they are "at arm's length", and it would be legal to do something like this if one bit was released under the GPL while the other was not. At the same time, it's possible to engrave (part of) an essay into a statue, for example. Or make a technical apparatus which looks like a statue but which will play music if you come near it. Both would be valid cases of some artist combining two separate and (at first sight) distinct things into one work.

Sure, you could crowdsource sculpture, but I doubt it will have much practical application. (And certainly difficult over the Internet, but I digress...)

It's called RepRap, and it's very much possible over the Internet. Joe moves on, with 'Unintended consequences of forkable prose'.

Take the GNU Manifesto, for example. If you could "fork" the manifesto, I could easily see variant versions modified to justify open source instead of free software.

This argument had been brought forward during the discussions which Debian had on the GFDL vote, and has been seriously debunked there. In short: the ability and right to fork someone's prose does not, in any way, give you the right to misrepresent them. While I believe it should be okay for someone to base a theoretical Open Source Manifesto on the GNU Manifesto, I do not believe it should be okay for them to still keep calling it the GNU Manifesto. It's not the same thing anymore, so that should be clear. This is true within Free Software as well: if you fork, you give it a new name, so it becomes clear that you're not the original anymore. Moreover, I doubt the kind of prose found in the GNU Manifesto is the same kind of prose that Nina would like to see in a free culture movement. Not because the GNU Manifesto is a bad piece of writing it isn't but because Free Culture likely focuses on other things than manifestos. Next, we get "Solving a problem that doesn't exist"

The spark that fired off the GNU revolution was a legitimate problem because of non-free code, a user was unable to make use of hardware they (or their university) legitimately owned.

(...)

While Paley and others may want the same freedoms to go with cultural works, it is not a real problem in the same sense.

Pardon ye me? I am a musician. Not a very brilliant one, mind you, but I play the flute with much enthusiasm, and have done so in a number of places. If you've been to any debconf since 2007, surely you must've heard me play. Also, I've been singing in choirs since I was sixteen which, I just realized, means I've now been singing for more than half my lifetime. Time flies, it must be said. One of the orchestra that I've been playing in was an extended flute choir with a rather unusual instrumentarium: apart from 30-something flautists, the orchestra also had a piano and drummer, a number of guitar players, and a bass guitar. Such an unusual set of music means you have three options: you play original music, written specifically for your group; you play something written for a different set of instruments, without changing anything, and hope nobody notices that it doesn't actually sound very well; or you make modifications. You make a derivative work of the music, so you can actually play it. There, I've said the word. This isn't just true for music; I've yet to see the first theatre performance that is true, word-for-word, to the original script. Also, movies use music all the time. When they do, there are usually two options: either they have original pieces of music written specifically for their movie (as is the case for most Hollywood blockbusters), or they take a piece of existing music, and adapt it so it fits the events in the movie better. By, say, shortening it, so it doesn't run into the next scene. Or by repeating the refrain an extra time, so the words line up nicely with the action. Or by having a group of musicians record a version of that piece specifically for your movie, which is the same thing in everything except the speed so that the feet of the actor walking on the big screen hit the ground in sync with the music. Or... well. You get the idea. By claiming that artists have no need to modify and derive from others, the only thing Joe accomplishes is to show that he really, really, really doesn't know what the fuck he's talking about. Artists have a need to modify other artists' works all the time. The only difference with free software is that they either need to invoke the fair use clause, or need to pay big bucks to the original rightsholder. Sound familiar? Joe finishes up with stating that despite all of that, Free Culture is still possible. And:

That doesn't mean that free culture is impossible. It simply means that different standards apply.

Exactly: different standards apply. And why? There is no good reason for that. Because people make money from cultural works? Well, money is made from software, too, that has never been a good enough reason. Because Culture is not functional? How many in the Free Software movement would even be willing to only be doing software all the time, and not ever do anything remotely related to Culture? None, I would say. Culture is just as functional as Software, it just serves different functions. In the comments, Joe clarifies that he isn't against people preferring not to use the ND clause in the CC licenses they select, he's just against demanding that others do the same. That argument would make sense if not for the fact that the FSF demands, mostly, that Software Should Be Free!!1!. By not complaining about the GNU Manifesto, but complaining about Paley's "Rantifesto", which basically complains about the lack of such an environment in the free culture movement, Joe just makes a fool of himself. Anyway, 'nuff said.

I watched the final shuttle launch this morning; for several years I've tried to catch shuttle events, knowing it would soon be over, but before that the shuttle had faded into the background for me as it did for so many of us. It was an impractical rocket to nowhere that we mostly only paid attention to when it blew up. Fourteen years ago today, Debian was flying in space aboard Columbia. According to the press release, it ran on an SSD on an embedded 486 in the lab module, and controlled plant watering, telemetry, and video. At the time, I had just become a Debian developer, and was very impressed to be part of a project that was involved in that. It was early days for Debian, and near the midpoint of the shuttle's thirty years. Now it seems likely that Debian, or its derivatives (or at least Free Software) will easily outlast that thirty year run, but I do wonder to what extent our work will fade into the background (and what interesting ways it will find to explode) over that time span and beyond. We'd say we have better methods than the centralized, committee-driven, top-down, PR-conscious NASA... impressive though it can be at its best. We have dreams just as noble as the ones behind the space program, but also goals that are more adaptable, equally at home flying in space, or emebdded in some pocket-lint laden artifact of a perhaps more contemporary inward turn.

I have been thinking of this topic for some time. I am a happy owner of the old Phat PS3 Model. At one time, I use to do a fair amount of gaming on my computers. So when Sony marketed the PlayStation 3 product, it was cool to see a machine that did:

1. Gaming
2. Movies, Music, Pictures
3. Blu-Ray
4. Ran Linux

I convinced myself to buy a PlayStation 3, that I'd use it for playing with Linux apart from gaming. The regular gaming did not excite any more, perhaps it had to do with the limitation of time. On running Debian on it, was when I realized that the Linux support was merely a joke. The Linux support included running a Linux distribution in a VM with not much access to the full hardware resources. Not a Great Experienceread more

Vincent, the right way to deal with missing locales on remote hosts is to not deal with them at all. On Debian wheezy and newer systems, eglibc contains the C.UTF-8 locale in the libc-bin package. This together with unsetting AcceptEnv (or when customized, removing LANG and LC_* from it) in sshd_config allows to get rid of locales on servers entirely (if you really require locales, then you would have installed locales-all anyway and the problem would not exist in the first place). Some time ago, I have backported the C.UTF-8 changes (1, 2, and 3) and applied to my build of eglibc for Debian squeeze. More information about C.UTF-8 can be found in #609306.

All started in December last year. I saw a red and a green pixel on my monitor. Moving the window containing the wrong-colors pixels corrected them. The wrong-colored pixels reappear from time to time in increased quantity. Then a second symptom appeared: The screen went black and came back one second later. This was triggered by moving a window and scrolling. I wasn t sure what the reason was. Either it was a bug somewhere in the X stack or some hardware was dying. dmesg showed multiple problems with the radeon driver:

[283808.667454] radeon 0000:01:00.0: ffff88021f815c00 unpin not necessary
[283808.667820] radeon 0000:01:00.0: GPU softreset
[283808.667823] radeon 0000:01:00.0: R_008010_GRBM_STATUS=0xE57024A4
[283808.667825] radeon 0000:01:00.0: R_008014_GRBM_STATUS2=0 00330302
[283808.667826] radeon 0000:01:00.0: R_000E50_SRBM_STATUS=0x200000C0
[283808.667832] radeon 0000:01:00.0: R_008020_GRBM_SOFT_RESET=0x00007FEE
[283808.682844] radeon 0000:01:00.0: R_008020_GRBM_SOFT_RESET=0 00000001
[283808.698840] radeon 0000:01:00.0: R_008010_GRBM_STATUS=0 00003028
[283808.698843] radeon 0000:01:00.0: R_008014_GRBM_STATUS2=0 00000002
[283808.698845] radeon 0000:01:00.0: R_000E50_SRBM_STATUS=0x200000C0
[283808.699845] radeon 0000:01:00.0: GPU reset succeed
[283808.717570] [drm] Clocks initialized !
[283808.765829] [drm] ring test succeeded in 0 usecs
[283808.765838] [drm] ib test succeeded in 1 usecs
[283808.765840] [drm] Enabling audio support
[283812.521265] radeon 0000:01:00.0: GPU lockup CP stall for more than 1000msec
[283812.521269] [ cut here ]
[283812.521294] WARNING: at /build/buildd/linux-2.6.35/drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0 365/0x3d0 [radeon]()
[283812.521297] Hardware name:
[283812.521299] GPU lockup (waiting for 0x00AE670A last fence id 0x00AE6705)
[283812.521301] Modules linked in: btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs nls_utf8 udf ip6table_filter ip6_tables binfmt_misc ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp kvm_intel kvm parport_pc ppdev snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 snd_ac97_codec ac97_bus snd_pcm snd_page_alloc snd_util_mem snd_hwdep snd_seq_midi radeon snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device ttm snd pl2303 drm_kms_helper coretemp usbserial joydev psmouse soundcore drm serio_raw intel_agp i2c_algo_bit lp parport hid_cherry usbhid hid firewire_ohci firewire_core usb_storage crc_itu_t e1000e ahci libahci pata_marvell
[283812.521360] Pid: 2194, comm: compiz Tainted: G W 2.6.35-24-generic #42-Ubuntu
[283812.521362] Call Trace:
[283812.521370] [<ffffffff8106089f>] warn_slowpath_common+0x7f/0xc0
[283812.521374] [<ffffffff81060996>] warn_slowpath_fmt+0 46/0 50
[283812.521390] [<ffffffffa01bd775>] radeon_fence_wait+0 365/0x3d0 [radeon]
[283812.521394] [<ffffffff8107f730>] ? autoremove_wake_function+0 0/0 40
[283812.521410] [<ffffffffa01bdf71>] radeon_sync_obj_wait+0 11/0 20 [radeon]
[283812.521418] [<ffffffffa01751a3>] ttm_bo_wait+0 103/0x1c0 [ttm]
[283812.521435] [<ffffffffa01d4e1a>] radeon_gem_wait_idle_ioctl+0x9a/0 150 [radeon]
[283812.521447] [<ffffffffa010f433>] drm_ioctl+0 463/0 520 [drm]
[283812.521465] [<ffffffffa01d4d80>] ? radeon_gem_wait_idle_ioctl+0 0/0 150 [radeon]
[283812.521470] [<ffffffff81162f0d>] vfs_ioctl+0x3d/0xd0
[283812.521473] [<ffffffff811637e1>] do_vfs_ioctl+0 81/0 340
[283812.521477] [<ffffffff811535f1>] ? vfs_read+0 181/0x1a0
[283812.521480] [<ffffffff81163b21>] sys_ioctl+0 81/0xa0
[283812.521484] [<ffffffff8100a0f2>] system_call_fastpath+0 16/0x1b
[283812.521487] [ end trace 6d5e03bab743abfa ]
[283812.521493] [drm] Disabling audio support
[283812.525575] [drm:radeon_ib_schedule] *ERROR* radeon: couldn t schedule IB(10).
[283812.525579] [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB !
[283812.527021] [drm:radeon_ib_schedule] *ERROR* radeon: couldn t schedule IB(11).
[283812.527024] [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB !
[283812.527921] [drm:radeon_ib_schedule] *ERROR* radeon: couldn t schedule IB(12).
[283812.527923] [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB !

The time between going black reduces every time. The system wasn t usable any more in the end. After testing that the screen was going blank on other systems like a live CD of Ubuntu and a not noteworthy proprietary system, it was clear that some hardware component was dying. My first assumption was verified after replacing it: My graphic card, a Radeon HD 4670, died. This was three weeks ago and around 25 month after I bought the graphics card. So I didn t have to worry if replacing the fan voided the guarantee, because the guarantee lasts only 24 month. Conclusion:

1. Not every error is a software bug.
2. The hardware component with the highest failure rate is the graphics card, followed by the motherboard. Four graphics cards died last year (in four different systems owned by four different people, in three different households).
3. Not every error is a software bug.

<meta content="text/html; charset=utf-8" equiv="content-type">

Hello,

This is the third report of my GSoC project for Debian. During last two weeks

I've done most of things about the main tool. Before that weeks I have been

working on project's API. API is almost finished. Still I find missing/wrong

parts during the coding and changing the API design.

Like I said, main tool's coding process is nearly finished. For now It is doing

its job for building Python3.X packages. You can find the source code at [1].

I also coded an example plugin (actually only return values) and plugins/__init__.py

file which contains like Base class, exception classes and plugin listing method.

When I started coding I realized that I need extra parameters. I've added --install-dir

parameter. You can specify the install directory if there is no install directory the tools

pretends that the install directory is "./debian/tmp". After that it checks whether if the

directory exists. If not it creates the directory.

I've changed py3build.py a bit. First, I've thought for every process I invoke py3build's

methods but they are redundant. I've removed them. Now they are called in main

method of py3build.

I use logging module for printing messages, errors etc.

get_build_system() method retieves list from plugins/__init__.py file. In that file there is

scan_for_plugins() method. It finds all plugins in plugins/ directory which files match for

"[a-zA-Z].py". It keeps the list in plugins_list variable and returns that. When I'm writing

scan_for_plugins() method I've read codes (f.e. [2]) about that and decided to name all

plugins' class name as *BuildSystem*. Now, detecting method works with that way.

(all plugins' class' are called BuildSystem) And I've changed base class name to

BuildSystemBase.

get_build_system() method is used by determine_build_system() method. If there is given

build system (by parameter) it tries to use that. If that build system is not usable then give

error and exits. If there is no given build system. It invokes get_build_system() and iterates

that methods return value which is a list. When iterating It create an instance of that build

system class (if can not create then it gives warning and skips that build system plugin)

and invokes detect method and append plugin name and detect method's return value to

the bs_list which contains plugin list which are available. And then sorts it. If there is error

while sorting list or there is no usable plugin then give error and exits. If there is multiple

highest detect values then lists that plugins and exists. (maintainer should select one of

these plugins to build extension.)

In main method, after getting arguments, it checks for verbose mode (or 'DH_VERBOSE'

environment variable) and sets log level (logging.DEBUG or logging.WARN)

If there is no given build_dir then it pretends it is "./".

After that It try to determine build system. If can not then prints error and exits.

And finally it starts to build extension. Firstly it checks if there is given version list. If not,

it uses default values and iterates build loop with that values.

First cleans, configures, builds (if there is no --test-only arg) and tests (if there is --test-only

arg or there is not --no-tests argument)

If there is error (raises plugin.Error) while invoking that method then prints error and exits.

In verbose mode tool prints every process. (like "configuring for PythonX.Y" etc.)

I've started writing a plugin for detecting *distutils*. For now, I only wrote its detect method. It

returns between 0-1.0 floating point value. If everything is OK it returns 1.0. Other methods does

nothing, only returns True but this week I'll finish this plugin and work for others.

For detecting distutils I've used the code at [3]. First I try to import that module if not, I've copied

required methods to plugins/_packaging.py file, I use them.

I don't use is_distutils() method directly. For give probability I invoke what it invokes and give them

a number. (f.e. _has_setup_py has 0.5, _has_pkg_info has 0.25 and _has_distutil_text has 0.25.

But if _has_setup_py returns False then detect method doesn't look other methods since they

require setup.py.)

For now that's all. See you at next time.

[1] git://git.debian.org/~<wbr>mesutcan-guest/py3multibuild.<wbr>git
[2] http://svn.berlios.de/<wbr>viewvc/griffith/trunk/lib/<wbr>plugins/extensions/

[3] http://hg.python.org/<wbr>cpython/file/a7e00934baf1/Lib/<wbr>packaging/util.py

--
Mesutcan Kurt

We are few weeks away from the start of DebConf11. Excitement runs high in Debian-land. The two most worthy weeks of the year, every year, loom close. Our Bosnian friends have done a great job of finding and defending an amazing proposal, and are now facing the hard work and permanent adrenaline levels of being in charge of the closest I have seen to a herd of (well-behaved but wild and untamable) cats. I have organized DebConf in my country. It was hellish, but at the same time, it's one of my most cherished experiences. And I'm sure the same will be said by the leaders of each successive bid It is one of the most rewarding experiences you can imagine. Next year, DebConf will be held in tropical Managua, Nicaragua. But, where will we meet in 2013? Well, that depends on you, my dear reader! Do you want to work your ass off for Debian and have utter fun? Do you want to show and share your country with this huge family of developers? Start thinking about pushing for a DebConf13 bid! Do you have to be at Banja Luka to propose your bid? No. You can proxy via somebody I'd suggest to do it via somebody who knows the location you are suggesting, but basically, choose a friend that you trust that trusts you. Of course, you can participate in the presentation session via IRC. Do you have to be a Debian Developer to propose a bid? No. For DebConf9, none of the C ceres guys was a DD; for DebConf10, some of the people most involved from the local New Yorkers were not DDs. For DC11, none of our dear and overworked hosts in Bosnia are DDs. And for DC12, the Nicaraguan crew is also made from people interested in getting closer to the Debian project, but not DDs. Do you have to decide now? No. This is just a call for a first presentation, but the decision regarding DC13 will be taken probably around March 2012. However, giving a nice presentation at DebConf helps a lot, gives you visibility, and will get the ball rolling. Is there a geographical bias? Slight. So far, and since the second DebConf, we have kept the tradition not to repeat continents on two successive DebConfs. This is not a hard condition, however! What do you need to start thinking about? Go visit our prospective location checklist at http://wiki.debconf.org/wiki/LocationCheckList. You can also look at what other teams have historically presented. Finally, I just learnt about the existence of http://wiki.debconf.org/wiki/DebConf13 Register there, even if you are just in the early phases of finding data. We will be holding a DebConf13 bids presentation session, most probably (the schedule is close to being presented officially!) on 30-07-2011, at 17:00.

Just published an ikiwiki plugin to add google's +1 buttons. See ikiwiki.info/plugins/contrib/plusone/ for details. And if you enable html5 in your ikiwiki settings, it won't show up on planet debian as ugly g:plusone tag.

Following a series of pre-releases, Armadillo version 2.0.0 was announced by Conrad Sanderson earlier in the week. As it happens, it contained another minor build regression so version 2.0.1 followed the next day. We created versions 0.2.24 and 0.2.25, respectively, of RcppArmadillo from this, and the latter release is now on CRAN. The NEWS file entries for both releases follow below; they include the aggregate changes some of which were already provided by the pre-releases leading up to Armadillo 2.0.0.

0.2.25  2011-06-30
    o   Upgraded to Armadillo 2.0.1 which fixes two minor compilation issues
0.2.24  2011-06-29
    o   Upgraded to Armadillo release 2.0.0 "Carnivorous Sugar Glider"
          * faster multiplication of tiny matrices (  4x4)
          * faster compound expressions containing submatrices
          * faster inverse of symmetric positive definite matrices
          * faster element access for fixed size matrices
          * added handling of arbitrarily sized empty matrices (eg. 5x0)
          * added loading & saving of matrices as CSV text files
          * added .count() member function to running_stat and
            running_stat_vec 
          * added syl(), strans(), symmatu()/symmatl()
          * added submatrices of submatrices
          * det(), inv() and solve() can be forced to use more precise
          * algorithms for tiny matrices (  4x4)
          * htrans() has been deprecated; use trans() instead
          * API change: trans() now takes the complex conjugate when
            transposing a complex matrix 
          * API change: .is_vec() now outputs true for empty vectors
            (eg. 0x1) 
          * API change: forms of chol(), eig_sym(), eig_gen(), inv(), 
            lu(), pinv(), princomp(), qr(), solve(), svd(), syl() that do not
            return a bool indicating success now throw std::runtime_error
            exceptions when failures are detected 
          * API change: princomp_cov() has been removed; princomp() in 
            conjunction with cov() can be used instead
          * API change: set_log_stream() & get_log_stream() have been 
            replaced by set_stream_err1() & get_stream_err1()

Courtesy of CRANberries, here is the diff to the previous release.

 ChangeLog                                         12 +++++
 DESCRIPTION                                       10 ++--
 inst/NEWS                                         36 +++++++++++++++-
 inst/include/armadillo_bits/arma_version.hpp      10 ++--
 inst/include/armadillo_bits/auxlib_meat.hpp        4 -
 inst/include/armadillo_bits/diagmat_proxy.hpp      4 -
 inst/include/armadillo_bits/fn_misc.hpp           58 ++++++++++++++------------
 inst/include/armadillo_bits/fn_princomp.hpp       31 +++++++++++++
 inst/include/armadillo_bits/subview_meat.hpp       2
 9 files changed, 126 insertions(+), 41 deletions(-)

More information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

Yeah! It's this time of the year: Friday evenings after work with your friends having some cool beer on the streets, Saturdays around the nearby mountains for a good hike and swimming in a lake or river, and good beach Sunday in a Valencian beach. And for a great ending of a Summer weekend, a good indie movie in your neighbourhood, reclaiming the streets and going back to our roots, when people perceived the public spaces as theirs, and would bring foldable chairs out, would gather with their neighbours and had a good after-dinner chat a la fresca. The always active Associaci de Ve ns i Ve nes de Benimaclet has organized, for the fifth year four cinema projections in Benimaclet's square, which are open for anyone who wants to share good moments with us. The program this year includes Soul Kitchen (3rd of July), When the Wind Blows (10th), Concursante (17th) and Moon (24th). Before every movie, we'll enjoy live music by local bands, and projections of good short films. We'll be happy to see you there, and remember you only need a chair and some dinner... but be sure to be there a bit before 22:00: last year this got so popular some people started having issues to find good spots for their chairs!