I ve spent a few hours going through all the unclassified important bugs assigned to iceweasel. This resulted in

• 6 confirmed bugs,
• 16 where the reporter is asked for something,
• a few merged,
• another few reassigned to other packages,
• and around 50 bugs closed.

In the closed bugs, there were several kind of bugs:

• the bug log shows that the bug eventually disappeared or was not a bug, but the bug was still opened,
• the bug has been known to be fixed for a while,
• the reporter is unreachable and the bug is unreproducible,
• the bug has been spammed by several different and unrelated me too s, leading the bug to being a huge mess where you don t know what was the problem to begin with (there were 2 such bugs, if I recall correctly), in which case I closed the bug, copying everybody and inviting to file individual bugs after confirming with newer versions.
• not a bug at all.

It will feel good when it will be visible on the bug graph. Still 500+ to go *sigh* Who wants to jump on the bandwagon ? ;)

A new release of Rcpp awaits inclusion on CRAN and has also been sent as a .deb to Debian. It will hit mirrors over the next few days, in the meantime you can get it here as well. This release has a couple new features :

• inline support: the cfunction from Oleg Sklyar's excellent inline package has been imported and adapted. This means simple C++ programs can be defined in an R character vector and passed to cfunction which will create a complete file that it then compiles, links and loads --- giving you access to compiled C++ code right from the R prompt without having to worry about compiler flags, linker options, ... Better still, we extended this to not only support Rcpp but any external library via addtional header / linker arguments that will be passed to R via the PKG_CPPFLAGS, PKG_CXXFLAGS and PKG_LIBS environment variables.
• this even works on Windoze (if you have the Rtools installed as detailed in the Windows Toolset appendix to the R Installation manual) in exactly the same way. And no folks, that still does NOT mean you can use Visual Whatever -- R really requires MinGW as the links in this parapgraph document very plainly. But if and when you have the tools, R's remarkable consistency across operating systems allows you to use Rcpp and inline in pretty much the same way.
• A handful of new examples for the inline support have been added.
• A new type RcppSexp for simple int, double or std::string scalars as well as vectors; this is particularly useful for the inline support.
• This also completes the source code reorginsation: every class now has its own header and implementation file
• Last but not least, the package has been relicensed from LGPL-2.1 (or later) to GPL 2 (or later).

Fuller details are in the ChangeLog on Rcpp page.

Tutorials at the Garching Debian Stammtisch Munich traditionally used to have a lot of Debian Developers, but over the last couple of years quite a few of us who used to be students graduated and moved elsewhere or became very busy with their day jobs. We still meet for having a beer and a chat, but not as much as some years ago. We used to meet about once a month, but in 2009 we only managed to meet four times (however, we organized a Bug Squashing Party in November and had a special meeting as Lenny Release Party in February) As the meetings are really rather informal and not necessarily very Debian related, it is difficult to attract new people this way. So Johannes Wiedersich and I decided to try a more hands-on approach by having a second meeting in Garching, in the student-run bar on the campus of the Technische Universit t M nchen (TUM). The idea was to get more of the local science, mathematics and computer science students (as well as possibly interested faculty members) involved. We tried a first time about a year ago, but after two or three meeting in late 2008 and early 2009, we lost momentum. However, we began organizing the meetings again with the start of the winter term, and had two rather successful meetings so far. For the first meeting, we basically handed out some information on how to get involved locally (the Debian-Munich list, its subscription address, the wiki etc.) and discussed Debian in general and Debconf11 in Munich in particular. About half a dozen people showed up, and two of these attended the Bug Squashing Party later that month, and another one (a faculty member) got very active in Debconf11 organization. Thus, I was quite happy with the outcame of that meeting. Some days ago, we had another meeting, and this time I was doing a live-tutorial on Debian package building. As Johannes was ill, we did not manage to announce or publicize the meeting well in advance, so only three people showed up. Still, I think it went rather OK, and we will be doing another Debian package-building tutorial for the next meeting, and possibly other turorials/workshops afterwards (ideas so far include library maintenance, Debconf, how the Debian community is organized and how to get involved in it). As doing a live-tutorial on one notebook is a bit difficult if you both have to type on it and people should see what happens, we will either use some extra hardware next time, or move to some nearby seminar room with a projector, this will be announced in advance. So if you are on Garching campus or nearby and interested in Debian development (and Debian package-building in particular), come to the next meeting on January 13th! We decided to meet on the second Wednesday of each month, at 18h. Subscribe to the Debian-Munich list to get the invitation or watch out for the flyers on the campus.

Some time ago I wrote a little utility named memlockd [1]. Memlockd will lock files into memory which allows significantly faster access when the system pages heavily, in my simulated tests I have found that having the programs and shared objects needed for logging in locked in memory can make it possible to login without a timeout when there is heavy paging, this can make the difference between recovering a system with some processes that are out of control and having to reboot it (often without discovering the root cause). As always happens some people use my software in ways that I never planned. One guy is using it to try and make OpenOffice.org load faster. I m not sure that this is a good idea. In a typical installation when configured for the purpose that I intended it (system recovery from a rabbit process) memlockd will take a bit less than 10M of RAM on an i386 platform (that is for bash, login, sshd, getty, busybox, and all necessary shared objects and a few data files. Since RHEL 4 Red Hat distributions have whinged at boot time if there was less than 256M of RAM available, installation of a Red Hat based system on anything less than 128M of RAM has been impossible for some years, and Debian systems perform very poorly with less than about 128M of RAM when you run apt-get. I initially designed memlockd to run on my SE Linux Play Machine which has 128M of RAM in it s current incarnation. Locking 7.5% of RAM on the system may impact performance, but as a large part of that RAM is used for things like libc and bash which tend to be partially paged in at all times this shouldn t be a noticeable impact. But locking 100M or more of OpenOffice seems more likely to have the potential to hurt performance, I often run OpenOffice on a machine with 512M of RAM and the biggest desktop machine I use has 1.5G of RAM for me it wouldn t make sense to lock OpenOffice into memory. But it could be that there is some unusual aspect of his system that makes running memlockd with OpenOffice likely to give worthy benefits in performance without significantly hurting performance for other programs, for example it could have 4G of RAM and a really slow disk. It is also a possibility that the usage of the system makes OpenOffice so much more important than other programs that any decrease in performance in other areas is not relevant. In any case I m happy to help people use my software to do unusual things so I ll support this use. I ve been asked why memlockd doesn t seem to give much benefit when starting up OpenOffice when run with +/opt/openoffice.org3/program/soffice.bin in the config file, where the + means to lock all shared objects that ldd reports that the binary needs. for n in ldd /usr/lib/openoffice/program/soffice.bin sed -e s/^.*=..// -e s/\ .*// sort -u ; do readlink -f $n ; done sort -u > ldd.txt I used the above command to get a list of all shared objects that ldd reports for the soffice.bin program. On my system (Debian/Lenny i386) it reports 77 shared objects loaded. When memlockd locks all those ps reports that the RSS is 51944K. cat /proc/1234/maps sed -e s/^.*\ // sort -u > /tmp/map.txt Then I used the above command to get a list of the files that are memory mapped by OpenOffice when running OpenOffice calc where 1234 is the PID of the soffice.bin process (I expect that the numbers will be similar for writer, impress, etc I just happened to have a spreadsheet open). It reports 172 memory mapped files which include 9 files related to fonts and 64 shared objects under /usr/lib/openoffice/program which are not found by ldd among other things. It s quite common for a large application to use dlopen(3) at run-time to map shared objects instead of linking against them. Running memlockd with this list gave an RSS of 118644K, which is more likely to give a useful performance boost to OpenOffice load times.

• [1] http://www.coker.com.au/memlockd/

I know, preaching to the choir and all that. But this can't be said often enough (and perhaps the odd non-Debian person stumbles upon this...): Here's another example of how amazingly fast free tech support works: The newest Linux kernel (Debian package version: 2.6.32-1) wouldn't boot on my QNAP TS-419P NAS (see also my earlier posting about the device). Now, since I don't have a serial console cable, I can't really help a lot to debug this (and I am extremely happy that the people at QNAP have thought about recovery: it's trivial to just flash a working kernel or firmware image via DHCP and TFTP), bu still Martin Michlmayr immediately took the time to help me and soon could reproduce it on one of his own machines. The problem has been identified, I got a fixed kernel, and a patch is on his way to the kernel maintainers. All in the after literally just a few days.

This is a bit of a silly note for a Saturday while I m currently working on translating the co-op s web pages into Esperanto. The old site was translated, but the new site launched as English-only. I d like to have other languages too, but I ll start with the one that s easiest for me as a test case to get the internationalisation working again. That means that I m currently lost in django-blocks language settings. Apparently both our co-op and Google speak Esperanto. Facebook is mostly translated. Most Plone-based sites have some translation, but often it s only the standard Plone parts and any customisations remain in English, which looks a bit odd. Have you seen Esperanto on other major websites where you weren t expecting it?

I just sent a data package representing TeleMetrum version 0.2 out for an assembly quote. Hope to have first article boards in hand before heading to linux.conf.au 2010 where Keith and I are scheduled to give a talk about the project.

As someone born in India, I sometimes look around and wonder, Where are the Indians (and other South Asians) in Free Software? (I don't mean to exclude South Asians from other countries, so I will lump us together. I believe that we are more similar than we are different, although I know more about India than about the rest of South Asia.) There is no shortage of Indians performing information technology jobs in the United States. The same is true in academia; the Computing Research Association uses National Science Foundation data to show about 15% of computer science bacholor's degrees are awarded to "Asians or Pacific Islanders." These are not precise numbers targeted at South Asians in particular, but they confirm a general feeling that plenty of technologists in the United States are from that part of the world. South Asia is quite a populous region, coming in at over one billion people. It, too, has plenty of technology workers. So much FLOSS conversation happens in English, and India is well-suited to handle this; English is an "official language". Indian academia reports that there are 350 million English users and about 90 million English speakers. So let's visually compare the Debian developers map for South Asia (over one billion people) and that of New Zealand, a country of four million. India: New Zealand: These two countries have about the same number of Debian developers (at least, who have marked their location in the Debian LDAP database). About four. South Asians comprise about one sixth of the world's population. There are about one thousand Debian developers; we represent at best 1% of that. These numbers are comparable to the under-representation of women in Free Software, especially when you compare the figure to South Asians' over-representation in the rest of information technology. That makes me sad. Take a look at the Debian developer map again. You'll see that Debian is certainly not an Americans-only project, or even an English-speakers-only project. South America has a respectable dotting of developers, and Western- to Central-Europe are packed. I have strong feelings about Free Software. It emerges from an ethos of personal empowerment, and with open source it has become a dominant force in computing. Yet there are plenty of sharp people -- at least women and South Asians -- who, somehow, become culturally excluded from participating.

Why care about diversity? Consider the diversity of contributors we already have. Some contribute to Free Software because of particular business needs, such as what caused Avi Kivity to write KVM, the new leader in Linux-based virtualization. Everaldo's art background gave us the "Crystal" icon set that set the standard for sharp-looking icons on the Free Desktop for years. Josh Coalson knew about compressing sound, and his Free Lossless Audio Codec is now the standard in high quality audio. We already have a great deal of diversity. We should be celebrating! Back in 2001, FLAC's users were celebrating. In that year, I decided to ditch proprietary operating systems because I felt I could achieve all my computing needs in the Free world. A happy user of FLAC myself, I lurked on the mailing list as I watched grateful people thank Josh for the great software he wrote. Different contributions will excite different sorts of users. The more different people we have improving FLOSS, the more happy users we can make. Happy users of FLOSS are Free users. Happy users can become contributors, putting forth code, documentation, translations, and word-of-mouth marketing. The first reason to improve diversity in FLOSS is to better suit our users' needs. The more diversity we have in our contributors, the more chance we have of tickling our users in the ways that please them the most. I wish to see an end to software that restricts users' freedom, so I want to see us build the tools that users want. One thing that pleases me is when I see other people contributing who seem similar to me. When I went to Debconf, I was thrilled to be surrounded by people who cared about software freedom and technical excellence. I had even more fun being social, chatting about rainforests, mutual friends, websites, and music. I might have had the most fun playing the card game Mao. A second reason, then, to improve diversity in FLOSS is to increase contributor retention by increasing joy. Mao was an example of a cultural bond I happened to share with a handful of Debianites. The more diversity we have, the more frequent these sorts of coincidences will be. The final, most obvious, reason to reach out to groups of people who do not typically contribute is that we can increase our numbers. That by itself is so valuable. Ubuntu sees 100 new bugs per week, even after the bug squad's efforts. If we can do a better job of recruiting new contributors, the raw numbers give us more strength in creating and maintaining world-class software as well as letting the world know about it.

Changing the balance I believe that there are plenty of South Asians quite capable of contributing to FLOSS. I believe the same of women. I believe the same of men. Back to the topic at hand. Why do the South Asians vanish when we look at Free Software, not tech in general? There are plenty of reasons I can dream up, based on my experience with Indians.

• Plenty of South Asian parents urge their children to make low-risk career choices.
• My mother reports that schools in India focus on memorization instead of creativity. This can leave little room for extracurricular pursuits.

It's tough for FLOSS advocates to work directly on these distant issues. But I think we can focus some problems we can help solve. Crucially, awareness of Free Software spreads best by social circles. I learned about Linux from a friend at a summer camp. I'll repeat that:

• Awareness of Free Software spreads best by social networks.

So if you want to spread that awareness, try to be a bridge. If you meet someone from an unusual background for open source who needs support or mentorship, try to help. That is an investment in the diversity and growth of Free Software. Those people can now unlock more "open source minorities."

What success looks like Google Summer of Code helps some new contributors get started and provides that mentorship. Rachel McCreary was invited to the SciPy conference after a successful summer. Her father left a comment explaining how her sisters participated in FLOSS via Google's Highly Open Participation (GHOP) Contest:

Rachel was inspired and motivated by BOTH of her little sisters, each completing six GHOP tasks (if memory serves).

GHOP and GSOC has been a game-changer for these girls. Rachel's younger sister is applying to schools such as MIT with an interest in a science major. The youngest daughter now has a Caltech poster on her wall with the intent to eventually attend.

Their proud Dad

Soon, these stories will be commonplace. Until then, we have work to do. (I'm still researching these topics. If you can help me find any sort of data to help me learn more about diversity in FLOSS, even if it seems like I wouldn't like it, leave a comment.)

As distributors we should not discourage upstreams that wish to generate binary packages themselves, rather we should cooperate with them, and ideally they will end up maintaining their stable release packages in our distributions.

-- Robert Collins I agree. Robert goes on to talk about the tendancy Debian (and apparently also Ubuntu) have to dislike upstream providing a debian directory. Funny thing is that we also like to say team maintenance is a good idea. An upstream who is doing packaging work is a readymade half of a team; if you write them telling them to rm -rf debian, you are turning away a team member. With a slap in the face. Worse, it's a team member who has demonstrated that they are capable of working in far more complex systems than a debian directory, since they wrote/maintain the software itself. BTW, for those who are skeptical of teams, on the basis that they dilute responsibility: A team consisting of an upstream developer and a distribution maintainer is inherently the more healthy sort of team, where each member has a well-defined area of expertise, but can also venture outside their area when needed. When I packaged FBReader for Debian, upstream already had their own packaging, and I worked with them to fix problems with it and make it something I could be happy maintaining. This was sometimes tricky, since upstream was also maintaining packages for maemo. Sometimes the tools were not ideal. It was still worth it. On the other side of the coin, d-i is an upstream for several distributions. If they told us we needed to rm -rf debian, we'd not have a lot of d-i left. tools I also agree with Robert that most of the trouble comes down to problems with tools. BTW, RPM does not have these problems, and in that world it's typical for upstream to provide a spec file. Much of the problem comes down to the crummyness of dpkg's source format, which cannot rename files, delete files, etc. That the source format directs us to 1970's source management (ie, tarballs and patches), instead of 21st century source management (ie, DVCS), doesn't help either. dpkg's 3.0 quilt source format tries to address the issue by removing any debian directory in upstream's tarball. I am not sure that this is at all the right approach; it makes it harder, not easier to work with upstream as a team. A better approach might be to consider anything that hardcodes the debian directory as having a bug. If upstream can easily package debs using a deb, or maemo, or ubuntu directory, you sidestep any potential conflict while still being able to work with them via a symlink. To put my time where my mouth is: Anytime debhelper prevents working with an upstream who wants to ship a debian directory; that is a bug. I will fix them. (Note that debhelper already provides a --ignore that can be used if upstream has provided a dehelper control file that you can't delete and don't want used.) Previously: Look who's packaging

We're doing a pilot to do remote logging for some Apache logs (possibly other services in the future). We've heard of remote syslog capability (and since syslog is on all Linux system) we're giving it a try.

The configuration is quite simple:

1. [srv] prepare a machine to do the log server
2. [srv] open it's rsyslogd to receive messages on UDP (or TCP) port
3. [srv] log the selected facility.level to a log file
4. [cli] forward the above facility.level to @srv<srv address="" ip=""></srv>

Ok, easy and it works. Unfortunately we face pretty fast the limitation of syslog:

1. only 8 facilities for users custom log (local0-local7)
2. only 8 levels for logs severity

this is a big block (only 64 combinations, if you agree to do some "dirty" stuff) if you want to log remotely several services on several different platform on the syslog server.

rsyslog is quite flexible and it allows you to filter messages based on the tag in them, and log in different files, but it's still something very "home-made" and not that professional.

I don't we're the only one needing a remote logging tool, and while syslog is the classic solution, is very bind to the system logs and not to the applications logs: any suggestions for this task? I'd like to hear how you solved this task, possibly without a custom tool, but using something standard.

For a very long time my laptop (running sid for a few years now) has been booting kind of slowly. It looked like there was a 2-3 second delay every time a kernel module was loaded, which resulted in something like 3 minutes total boot time. Never bothered me enough, but yesterday I've finally got some time to investigate. After increasing the verbosity of udev logging in /etc/udev/udev.conf I've found lots and lots of messages like this in the log:

Dec 18 00:41:46 droopy udevd-work[425]: wait for '/sys/some/path/bInterfaceProtocol' for 20 mseconds

The only udev rule file containing a reference to bInterfaceProtocol was /etc/udev/rules.d/z60_libccid.rules with the following lines in it:

# last file created by the kernel, if this is present everything should be
WAIT_FOR_SYSFS="bInterfaceProtocol"

The libccid package itself is long gone (I don't remember installing it at all), and the versions of the package starting with 1.3.4-1 (uploaded in February 2008) do not contain this rule. However, the file survived on my system, so this rule was continuing to trigger for every device, even the ones not providing the bInterfaceProtocol at all. Removing the now-redundant file resulted in a dramatic boot speedup (it now takes about 30 seconds), so if you are experiencing similar problems, you might want to check it out.

Widgets are little web applications run on the client side. They re not particularly new and there are a lot of them about, but there s little consistency between them, so they re a bit of a pain to use in practice still. The good news is that W3C have published Widget Packaging and Configuration W3C Candidate Recommendation which should help to encourage consistency. The bad news is that Apple has made patent claims about the Widgets 1.0: Access Requests Policy First Public Working Draft. A Patent Advisory Group has been set up, which means that Apple s patents have probably delayed that part of widget standardisation to at least next February. You may remember that Apple also patent-bombed the Widgets Updates work earlier this year and work has only just resumed after the patent detour. Two things come to mind:

1. Why are Apple being the new World Wide Wallies?
2. Can someone see how to total up the delays to W3C work caused by patents? That might be useful for anti-patent campaigns.

gfcombinefs is a side project I did some work on a few weeks ago. It combines several "shares" of a secret file previously split using Shamir secret sharing, to produce the original secret, and presents it as a file in a FUSE filesystem. It uses libgfshare for the actual mathematics, and expects its input to have been split with the gfsplit tool shipped with libgfshare. At this stage of development, I suggest not trusting it with important data, like the GnuPG secret keyrings it's designed for. However, I hope that with some feedback from others I can get it into a state where it's ready to be released and packaged (perhaps I'm being unnecessarily conservative, but for something that deals with GnuPG keys, it seems wise to be careful). Source code is available in a git repository, and I'd welcome contributions, bug reports (other than the limitations that are already listed in the documentation) and in particular, a systematic code audit from someone (the good news is that there isn't very much code, so that shouldn't actually take long).

Hello, google. I would like to introduce you to our chat logs. Chat logs, google. Google, chat logs. We will discuss things here such as Mono, GNOME and Debian. We may even use it to talk about work on the DLR project stuff.

Despite my position on shell scripts (see sh), one of the bespoke packages in Debian that I look after, game-data-packager, is written entirely in bourne shell. This is partly a result of it's origins: game-data-packager grew iteratively from hacky shell scripts that did specific jobs to install non-free game data into a Debian system. As game-data-packager has grown, I've wanted to write a regression test suite for it. Yesterday I learned of a framework for doing this called shunit2. I don't have any experience of other testing frameworks for comparison, but it looks well written and potentially very useful. Today I discovered that a Debian package for it is being worked on. It also turns out that shunit2 was briefly in unstable and testing 2 years ago, but was removed not long afterwards.

Here it is: http://paste.debian.net/54275/. It needs /usr/bin/cupt from testing or unstable to work. Please report bugs or suggestions in comments to this post or anywhere where you can reach me.

Typical usage:

1) './script package.dsc -s' - preview
2) 'sudo ./script package.dsc' - do the work

Type './script' to see usage.

I will move it to more permanent storage soon.
UPD: Moved. http://people.debian.org/~jackyf/satisfy-dsc-deps.