December 20, 2009

RCBW - week #15

Here are ~~last week~~today squashes, by yours truly:

bug #546585 - cssed - invalid const char* conversion (Ubuntu patch)
bug #434925 - suikyo - prefer recent emacs in suikyo-elisp
bug #545515 - mgltools-gle - move to non free due to NC clause (copyright patch by Scott Kitterman)
bug #548555 - lastfmsubmitd - fix deps in init.d LSB headers (patch by Peter Reinholdtsen)
bug #554905 - hibernate - fix deps in init.d LSB headers (patch by martin f krafft)
bug #554494 - pfstools - invalid const char* conversion (Ubuntu patch)
bug #551718 - eboard - invalid const char* conversion (Ubuntu patch)

Some highlights:

last week I've been incredibly busy at work to finish up some pre-xmas-holiday duties: hence today I've took half a day of BSP at home to "catch up"
the above finally convinced me to drop the dates from my reports, they are quite pointless: my personal goal is simply one RC bug per day on average, the actual day of the week is irrelevant
Lucas strikes back: the huge peek up in the RC bug graph is the result of his last rebuilt, several (most?) FTBFS new bugs are due to the recent switch to gcc 4.4 (err, of course thanks Lucas for his rebuilds, they are a significant part of our QA efforts)
... the good news is that Ubuntu has apparently switched to gcc 4.4 already and most gcc-4.4-related issues come with a patch from them. In particular, several of the bugs fixed above thank Fabrice Coutadeur from Ubuntu for his patches
my Luk's bug feed is empty again ..., pretty please?

20 December, 2009 03:11PM

Wouter Verhelst

Re: Grrr

I received a number of comments on my "Grrr" post, all of which missed the point:

Yes, I am aware that there are many more ways to fix this issue beyond a memcpy. However, the example code is legal and would not crash the application, if not for the fact that libc thinks I am doing something wrong. On top of that, this kind of overflow "protection" only kicks in when the code is compiled with -O2 rather than with -g -O0. While I am not sure whether the difference is due to the absense of debugger symbols, or rather due to the different optimization levels, fact is that software which runs fine in debugging should also run fine in production.

There are good arguments for compiling all C code with -Wall -Werror, and I do that as a matter of course for all C software that I write. However, sometimes automated tools are just wrong in their compile- or run-time bug detection, in which case such it should be possible to disable that detection. This is one such case, and my blog post was more about ranting about the inability to do so, rather than about the fact that I had to memcpy when in fact there were other options available.

But yeah, perhaps I should have been clearer about that. Forgive me for not being clear after having fought with compilers for far too long.

20 December, 2009 02:57PM by Wouter Verhelst (w@uter.be)

Good, not evil

There is a bit of a fluff online currently about the following clause in the "jsmin" code (whatever that is):

The software shall be used for good, not evil

This seems to have started when Google rejected a project based on that code due to its license being not free or open source according to their standards, and therefore not welcome anymore.

The arguments then quickly degenerated into things like 'when did google stop being against evil'. But those are all besides the point.

One of the most important properties of free and open source software is that anyone can use it for any purpose; there are no restrictions to using them. The DFSG (and hence, the OSD which was derived from the DFSG) encode this as follows:

No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

You may think "how is 'evil' a field of endeavor", but that is the wrong question. To "use software for evil" can mean any of a number of things, including "nuclear research", "weapons development", "abortion", or, heck "the cash register in a butchery shop", depending on the ethical and moral framework through which the person writing the license sees the world.

The ability to give someone a CD or DVD with a bunch of software on there, being able to tell them that they can just use this in any which way they see fit, is a very strong and important feature of the free and open source community. Every time someone comes up with a clause like the above, however, this ability is diluted somewhat; and if it is readily accepted within the greater free and open source movement, then eventually everyone interested in using a piece of software must first check whether they're not trying to use software that forbids someone's pet evil, and we lose one of the greatest strenghts that does exist for free software, but not for proprietary software.

The sad thing is, the jsmin author seems to agree. From a video/transcript on which he talks about his absurd license clause is the following quote:

Also about once a year, I get a letter from a lawyer, every year a different lawyer, at a company – I don't want to embarrass the company by saying their name, so I'll just say their initials – IBM…
[laughter]
…saying that they want to use something I wrote. Because I put this on everything I write, now. They want to use something that I wrote in something that they wrote, and they were pretty sure they weren't going to use it for evil, but they couldn't say for sure about their customers. So could I give them a special license for that? Of course. So I wrote back – this happened literally two weeks ago – "I give permission for IBM, its customers, partners, and minions, to use JSLint for evil."

Or, in other words, all you have to do if you want to use this software for evil is set up a second company, tell Douglas that this second company wants to sell software that uses his software to people who might use it for "evil", even though the first company won't, and you're in business. Because Douglas doesn't really oppose evildoers.

So the question is, why is that clause in there in the first place? There are only two possibilities; either Douglas didn't really think about those issues, in which case I hope he will one day see the light and remove the clause; or he did, and decided to go ahead and put that clause there anyway. And that would be evil.

20 December, 2009 02:17PM by Wouter Verhelst (w@uter.be)

QNAP NAS device

A customer called me a while back.

They have a pretty high-end NAS (2U server with external disk enclosure) that they use for most of their needs: both document and other storage for management types, as well as storage for their EDA cluster. People familiar with EDA tools will know that they are pretty disk intensive. They tend to require shitloads of diskspace, preferably at high performance.

The problem was that extending the storage space of this high-end NAS device is rather expensive. Supported disks only come at 300G units with prices that are higher than the cheap TB disks available today for the desktop market; and while the price and performance of those disks is worth it for the EDA requirements, the number of people storing documents and similar on the same device is not so high that performance would be an issue.

Thus, what they wanted was a cheap solution to augment, rather than replace, their current storage solution, with the focus being on low cost at the possible expense of performance and, since bacula runs well there, reliability.

They were quite surprised when I offered them a solution based around a QNAP device; they had expected a price, without hard disks, of about three to four times the price of the QNAP, and therefore were very happy with this suggestion. Unfortunately, the devices produced by this manufacturer that are supported by Lenny, the current Debian stable release, were EOL'd just before we placed the order; however, their replacements will be supported by Squeeze, the next release, and with a bit of help from Martin Michlmayr, we were able to install Lenny with a somewhat more recent kernel. This drove the price up somewhat, both because the newer devices are a few tens of euros more expensive, and because we agreed to pay Martin to prioritize work on the specific device that we'd need, so that we wouldn't have to wait for him to get around to it.

As of this Thursday, the device, which had finally arrived after some initial delays, has been installed. Unfortunately, one of the disks that they'd bought was DOA; but they had the foresight to buy five, rather than four, disks, so that was not a major problem. In fact, the only real issues that I ran into were this one arm-specific bug, and the fact that the high-end NAS device is still running etch, which means that rsync --acl won't work. That means I'll have to go back there soon to do an upgrade of the high-end device (which had been planned for a while already); for the arm-specific bug, a workaround is already in place.

All in all, a pretty good experience.

20 December, 2009 01:59PM by Wouter Verhelst (w@uter.be)

Daniel Stone

don't be evil

'I give permission for IBM, its customers, partners, and minions, to use JSLint for evil.'

20 December, 2009 01:17PM

Robert Collins

Various releases

Recently I’ve been working on the Python unittest API in my spare time, with a long term goal of making it possible to safely and sensibly glue many different plugins together into the core.

Two important components of that goal are being able to extend the data included in a test result, and being able to change how a test is run (such as adding new exceptions that should be treated as specific outcomes – python unittest uses exceptions to signal outcomes).

In testtools 0.9.2 we have an answer to both those issues. I’m really happy with the data included in outcomes API, ‘TestCase.addDetail’. The API for extending outcomes works, but only addresses part of that issue for now.

Subunit 0.0.4, which is available for older Ubuntu releases in the Subunit releases PPA now, and mostly built on Debian (so it will propogate through to Lucid in due course) has support for the addDetail API. Subunit now depends on testtools, reducing the non-protocol related code and generally making things simpler.

Using those two together, bzr’s parallelised test suite has been improved as well, allowing it to include the log file for tests run in separate processes (previously it was silently discarded). The branch to do this will be merged soon, its just waiting on some sysadmin love to get these new versions into its merge-test environment. This change also provides complete capturing of the log when users want to supply a subunit log containing failed tests. The python code to do this is pretty simple:

def setUp(self):
    super(TestCase, self).setUp()
    self.addDetail("log", content.Content(content.ContentType("text", "plain",
        {"charset": "utf8"}), lambda:[self._get_log(keep_log_file=True)]))

I’ve made a couple of point releases to python-junitxml recently, fixing some minor bugs. I need to figure out how to add the extra data that addDetails permits to the xml output. I suspect its a strict superset and so I’ll have to filter stuff down. If anyone knows about similar extensions done to junit’s XML format before, please leave a comment

20 December, 2009 01:15PM

Russell Coker

I Bought the Bose QC-15

I bought the Bose QC15 noise canceling headphones for my trip back from the US. See my previous posts about Noise Canceling Headphones [1] and Testing Noise Canceling Headphones [2] for the details of my search.

I first tried my new headphones in my hotel room and they worked really well at blocking the noise from the nearby road (El Camino Real in Menlo Park) as well as the noise from the heater in my room. At the airport they entirely blocked the sound of the airport air conditioning system (which was surprisingly loud – I didn’t realise how loud until I tried the headphones).

On the flight the headphones worked really well. I used them for hours when they weren’t plugged in to any source, just stopping the noise was a huge benefit. I was also able to listen to music (both MP3s on my laptop and the plane sound system) at a relatively low volume with an apparent high quality. The Bose store I visited in Stanford mall has a sound system set up to emulate the noise you experience inside a jet to demonstrate what the headset can do. It really lives up to this demonstration! I recommend them to anyone who wants over-ear noise canceling headphones and can afford $US300 + tax.

But one thing to note is that not everyone likes such things – my wife didn’t like the sound that they generate (the least bad way to describe it is as a soft hiss). This is definitely not something you would want to buy based on reviews alone, it must be tested in-store.

The main technical suggestion I can make for improvement to the QC-15 is for it to have slightly softer and thicker padding where it contacts the sides of the wearer’s head. I find that my glasses prevent it from making as good contact as I would like, and that when wearing it while eating the contact is significantly broken with every jaw movement which is really annoying. A minor suggestion is that every pair of headphones should have the left and right ear pieces clearly marked, I really shouldn’t have to read an instruction manual to discover which way to wear it.

One thing that surprised me was the inclusion of business cards for the headset! Here is a picture:

The picture links to a larger picture that also shows the French version of the same text on the other side.

I was astonished by this, encouraging happy customers to help sell your products is a reasonable and effective form of product promotion (really this is what I’m doing for Bose with this blog post). But giving customers business cards is going too far – anyone who wants me to hand out their business cards can offer to pay me to do so (and I probably won’t accept). But if such things are considered to be a good idea then here are a few suggestions for other things that they could do:

Create a Bose dating site where one can meet people who like music and traveling (this does sound appealing). In about 10 years the children of people who meet that way would start buying audio gear…
Start a Bose fan club.
Create a template that be used by a tattoo parlor to make a Bose tattoo.
Sell Bose fan t-shirts to people who aren’t dedicated enough to get a tattoo.
Register Bose as a religion, that gets tax free status among other benefits.

It’s a pity that Bose doesn’t make any water-proof noise canceling headphones. It would be something for their marketing people to wear while jumping over a shark on water skis [3].

But seriously the best thing that Bose could do to have their products promoted would be to start by printing the web site for each product on the item, my headset has two patent numbers listed which seem unlikely to provide any benefit for anyone, in that space they could have printed the global.bose.com/qc URL that is on the business card. Of course providing the URL really doesn’t do any good when the URL actually is useless. It starts by giving me a page asking which country I am in – the correct thing to do is to use geoip to determine the country and then give the user the option of selecting another country if that one is not ideal. Then after I select a country it doesn’t take me to a specific page for the product! I could have typed in www.bose.com and got the same result (in terms of US shopping at least) while typing six fewer characters!

Next like most corporate web sites the Bose site doesn’t appear to be configured for longevity of URLs – URLs which are clearly designed for the computer rather than humans are expected to change without warning. This discourages linking to any page that one might discover through web searches or navigating the site, and causes them to lose a lot of potential links.

Having specific URLs for all the products (including the obsolete ones) that are designed firstly for humans to read and write would be a good idea. It would be really useful to be able to compare the features of new products with the ones that are going cheap on eBay. For someone who is considering buying a new product now the purchase decision would be easier if they knew that the company would provide resources to help them get a better price on eBay in a few years if they want to upgrade to a newer model. One thing to keep in mind is the fact that the reputation of a company (which makes a dramatic impact on the prices customers are prepared to pay) depends largely on a long history of making quality products. Telling customers about those historic products is one of the most sensible things that most corporations fail to do on the Internet.

20 December, 2009 12:58PM by etbe

Romain Francoise

Defining evil

How exactly are these packages DFSG-free? (via, via)

20 December, 2009 11:57AM by Romain Francoise (noreply@blogger.com)

Christian Perrier

Font packages moved to source v3

Today, Hideki Yamane completed his work on the last four packages maintained by the Font packaging Team to make them switch to source v3.

Along with these changes, we also moved all our packages to debhelper v7 and minimal rules files. We also dropped the dependency on the obsoleted defoma.

The team maintains 77 source packages for fonts and has now built a quite solid experience in this. In the upcoming weeks, I'll try to get in touch with other people who maintain fonts, inviting them to join the team and maintain their packages in our SVN (we don't do very fancy things so SVN is very well suited for such work). The maingoals will be to continue dropping support for defoma (dropping defoma hints files: you can see good examples on how to do this properly in packages maintained by the team, such as ttf-dejavu).

We also intend to drop useless Recommends or Suggests that appear in some font packages (often on "x-ttcidfontconf | fontconfig" which is now completely useless) as well as harmonizing package naming schemes (with a "(ttf|otf)-<foundry>-<fontname>" scheme).

Feel free to join and share your advice and thoughts about The Right Way To Maintain Font Packages on our mailing list.

20 December, 2009 11:21AM

Julien Danjou

Teething troubles

It's not that often that I start something from scratch. It's an amazing feeling to start a new project, to start writing something new. I like that. It's creation, it's an artistic part of our computing stuff. I feel like a code artist.

And what I like even more is that little feeling that you are going in an unknown land. Some area in this tech world where nobody ever came before you, or only a few pioneers.

That the sensation I got starting to using Cython, Python 3 and various other tools. I just spent half of my time trying to fix problems, rather than working on *my* code. Problems in autoconf macro not knowing Python 2.6 or Python 3.1. Problems and limitations in Cython. And problem in Python.

That last one was a hard one. I'm still a beginner in the Python world: I barely know anything. And I was trying to use something nobody never did: building an embedded Python with a set of built-in modules.

I spent hours trying to find why one type of module importing was badly failing. I finally found the answer thanks to a guy. who has the same problem A guy ? No. A pioneer. What do I say? A hero. He's been my week-hero! Thank you Miguel Lobo because you found the bug I chased for hours and because you even reported it as issue 1644818, including a patch! How not damn wonderful is that?

I will not bore you with the technical details of that bug, since nobody cares. Nobody cares, even the Python guys, since that bug has been opened for 3 years, and nobody even reviewed in that time. I found an old thread about that bug where some guys were wanking about how they should do the review, because Miguel pushed for several weeks to have a review, back in 2007.

But that bug was in my way. I had to do something. So I prepared my mail reader, mounted my web browser and here I was for a uniq quest: getting a Python bug fixed.

At that point, if you did not stop reading earlier, you might get very excited. Don't be, spoiler, it's still not fixed. You'll have to wait the end of the season and see all the episodes I'll have to write to get the end of the story!

Let's continue.

I had to create an account on the Python bug tracking system. That was a trivial task for a man like me (you bet). Then, I launched a verbal attack, something you rarely see in a bug tracking system. Something I knew would awake any developer caring about their software.

Julien Danjou: Is there any chance to see this *bug* fixed someday?

I had the deep feeling that my quest was starting here. How many days would I have to wait until I get an answer? Time was passing. Minutes were ticking while I was waiting, sat in a comfortable sofa in a softly lighted room. It seemed like all my life was shorter than the delay I had to wait to get an answer.

After waiting for hours, suddenly, and only 15 minutes later, I got an answer:

Martin v. Löwis: Please ask on python-dev. I may be willing to revive my five-for-one offer.

Martin? Don't know that guy. Who is he? Who is he like? Will he fix that bug? What is this offer? So many question without an answer. But he asked to ask on python-dev, and I said: challenged accepted! I will write a mail to python-dev to get that bug fixed.

Which I did. I sent a short (but well written you know, I made efforts) "WTF?" to pyhon-dev.

And then the guy asked me to review 5 bugs so he will review and fix this one. And this is how I said that he was pissing me off for blackmailing me to fix a bug that was its "duty".

Therefore, this is the end of the story so far. Will that bug be fixed some day? There's a hope, because another guy jumped in and took the bug assignment.

To be continued.

My conclusion about all that story: that is a little rude to start something new, with new tools, and get quickly into teething troubles. It's even more harsh to enter a community because you just found bugs, and be not very well received when you ask to apply a 10 lines long fix somebody wrote 3 years ago to fix it.

I'll probably still use Python :-), but I get a darker image of its community now.

20 December, 2009 10:59AM by jd

Joerg Jaspert

Dinstall status

If you are one of the majority of people that have no access to Debians ftp-master host, but still do want to know in which state our main archive update, the dinstall run, is: http://ftp-master.debian.org/dinstall.status to the rescue.

This file is now updated during dinstall. It is not telling exactly which function is currently running, that would be too much detail (we have over 50), but it is giving a good overview of the area dinstall is in. There are currently 6 states it reports:

Startup Here we do an initial backup dump of our database, update various external resources like the i18n/ structure.
Indices During that part we generate various files you can find in indices/ and prepare everything for the next state.
packages/contents This part is currently one of the longest running, the actual write-out of our Packages/Sources and Contents files. Expect that to stay around for an hour til two each time.
dists/ Directly after the packages files. Everything thats needed to finish the dists/ directory, like creating the (much hated) pdiff files and the release files.
scripts We run various small actions in here, including the final preparation for the mirror tree, making all the changes visible to the world.
postlock From here on a lot of actions run in parallel. Basically general cleanup and householding actions that do not modify the visible archive.
all done Who would have thought, we are all done.

The format of the file is pretty simple, it consists of 3 lines, at the time of writing this blog post it looks like

Dinstall start: Sun Dec 20 07:52:01 UTC 2009 (1261295521)
Current action: scripts
Action start: Sun Dec 20 09:12:08 UTC 2009 (1261300328)

It tells when dinstall started, what the current action is and when that one started. In case you want to do some math on the dates it is also provided as an epoch.

Have fun.

20 December, 2009 09:18AM by Joerg Jaspert

Debian News

Updates on LXDE

Several LXDE components have been updated recently in sid. They bring some new features and improve flexibility of customization. Below you have a summary of the most important changes:

lxde-common 0.5.0-2:
The nuoveXT2 icon theme has been removed from lxde-common and it is has been moved to lxde-icon-theme package instead.
The startlxde script now executes 'lxsession -s LXDE -e LXDE' rather than 'lxsession -s LXDE' to reflect the changes in lxsession.
lxsession 0.4.1-1:
There is a new command line argument: -e. This let you set the internal name of the DE. This value is exported via the environment variable $XDG_CURRENT_DESKTOP. The DE name can be used to match desktop files which contain compatible OnlyShowIn and NotShowIn key values.
The -s argument is reserved for session name only and was used to load related config files for the desktop session. For example, you can execute: lxsession -s Lubuntu -e LXDE This should load config files from Lubuntu directory, but the DE is still recognized as LXDE by applications.
lxpanel 0.5.4.1-1:
Now you can determine the visibility of applications in the menu by comparing OnlyShowIn and NotShowIn key values and $XDG_CURRENT_DESKTOP. This means, you can have lxpanel show Gnome menu by the following export XDG_CURRENT_DESKTOP=3DGNOME . Then lxpanel will show gnome applications instead of LXDE ones.
Finally, lxnm and lxpanel-netstat-plugin are now deprecated.
lxnm has been already requested to be removed from the archive and it is recommended to use wicd instead. lxpanel-netstat-plugin has also dropped from lxpanel in the upload 0.5.4.1-1.

Contributed by: Andrew Lee

20 December, 2009 03:11AM by ana

hackergotchi for François (fmarier@gmail.com)

Francois Marier

Debugging logcheck rule files

logcheck is a neat little log file monitoring tool I use on all of my machines.

I recently noticed however that I hadn't received any logcheck messages in a while from one of my servers. Either that was a sign that things were going really well or, more likely, that logcheck wasn't producing any output anymore.

Manually logging an error to syslog

Here's what I did to force a message to be printed to the logs:

logger -p kern.error This is a test

Which I would expect to produce this logcheck notice:

Dec 20 15:34:08 hostname username: This is a test

Unfortunately, that didn't happen on the next scheduled run.

Forcing a logcheck run

To rule out the following:

mail not getting through
cron not running

I ran logcheck manually:

sudo -u logcheck /usr/sbin/logcheck -o -d >& logcheck.out

Looking at the output file however, my test message still wasn't there. Either logcheck was broken or one of my rule files was swallowing everything.

Finding the broken rule file

To find the broken rule, I started by ignoring rules defined in /etc/logcheck/ignore.d.server/ and /etc/logcheck/ignore.d.workstation/ by running logcheck in paranoid mode:

logger -p kern.error This is a test
sudo -u logcheck /usr/sbin/logcheck -o -d -p >& logcheck.out

This worked, so I then ran logcheck in server mode:

logger -p kern.error This is a test
sudo -u logcheck /usr/sbin/logcheck -o -d -s >& logcheck.out

Given that this also worked, it meant that the offending rule file was in /etc/logcheck/ignore.d.workstation/. So I moved all of my custom local-* rule files out of the way and ran logcheck in workstation mode:

logger -p kern.error This is a test
sudo -u logcheck /usr/sbin/logcheck -o -d -w >& logcheck.out

Once I verified that this worked, I started to put my local files back one by one until it broke again. Then slowly removed lines from the offending file until it worked.

Solution to my problem

It turns out that one of my rule files had a line like this:

path != NULL || column != NULL

Escaping the pipe symbols with backslashes solved the problem:

path != NULL \|\| column != NULL

Maybe I should periodically print a message to syslog to make sure that logcheck is still working...

20 December, 2009 03:09AM by François (fmarier@gmail.com)

Jose Luis Rivas Contreras

Collecta, searching on real-time

Real-time search on Collecta of xscreensaver

I haven’t read of it, and it seems it has been around since a good time. Collecta is a search engine for things in real-time. It searchs on Twitter, Identi.ca, Youtube, Flickr, Blogs, Ustream and shows you what people is saying.

It’s like a meta-searcher, I guess using API’s from those services. But it has it’s own API so it will be great for someone that’s into web2.x and wants information on real-time from everywhere with just one API. There’s a lot of people doing this already and there’s a gallery about their development.

Maybe tomorrow I will get a little into it, it looks really nice.

BTW, it’s what powers search.identi.ca

20 December, 2009 01:10AM by ghostbar

December 19, 2009

hackergotchi for sp (noreply@blogger.com)

Stephan Peijnik

Rest in peace Flo: 13.11.1986–16.12.2009

Today is a sad day. Everything feels like I am having a bad nightmare. That's because today I learnt from the too early death of my friend Florian Hufksy.

I am sitting here and do not really know what to write. I keep on thinking about the great times we spent together. The time we started programming when we were twelve. The time we spent learning BASIC. All the times you knew more than me and could teach me a thing or two. I remember our geek talks. How we would discuss latest games. How we lost contact and how we met again. I am thinking about how sorry I am for not having met you often enough. I keep on trying to understand what drove you that far. How you could just end it all. More and more memories come to my mind, like the moment when you showed me one of your projects, Super Mario War. The moments we had playing video games together. All those moments, all that time, I miss you my friend. You were a genius, always a step ahead, not only of me, but seemingly the whole world. I can't stop thinking about your brilliant ideas and how you always finished your projects. You were a real hacker, a real genius, a person trying to make the world a better place, a person who will be missed, not only by me.

You were a genius and I always respected you, not only as a hacker, but as a beloved friend. Why did we not spend more time together? Why did you have to go? Why do I have to write this now, sitting here in my chair with tears in my eyes? And all those memories come up again and again. There is so much more that comes to my mind, but I can't keep on writing, it just hurts too much.

The world is a sad place today. I am sad. I am mourning the too early death of my beloved friend, Florian. You will always have a special place in my heart.

19 December, 2009 11:15PM by sp (noreply@blogger.com)

Frans Pop

debmirror IV

The Debian FTP-masters recently changed the way gzipped meta files are compressed in order to make them more efficient to update using the rsync option. This was done by adding the --rsyncable option when calling gzip.

Consequence was however that when debmirror compressed Packages, Sources and Contents files after updating them by applying diffs, the md5sum of the gzipped file created by debmirror no longer matched the md5sum listed in the Release file (because debmirror did not use --rsyncable).

Result was that debmirror would also download the full gzipped Packages, Sources and Contents files from the parent mirror, something the diffs are meant to avoid. Not nice.

Anyway, this has been fixed in debmirror 2.4 which now by default also uses --rsyncable when gzipping the updated meta files.

I've also uploaded a fixed version for Lenny (20070123lenny1), which should soon be available from proposed-updates and will be included in the next stable point release.

For archives that also provide diffs (most archives don't have them) but do not have rsyncable gzipped files, the default options used when calling gzip can be overruled using the new option --gzip-options (only in version 2.4).

Tip: if you are using the rsync method to download files, using --diff=none may well be more efficient now that the archive has rsyncable gzipped meta files.

Version 2.4 also has a few other improvements and fixes. If you're currently using version 2.3.x an update to the new version is probably a good idea.

19 December, 2009 10:39PM

Lior Kaplan

Use signed packages from a trusted source

Use signed packages from a trusted source or suffer the consequences.

Malware Hidden Inside Screensaver, Theme on GNOME-Look.

As it turns out, two malicious software packages had been uploaded to GNOME-Look.org, masquerading as valid .deb packages (a GNOME screensaver and theme, respectively).

Posted in Debian GNU/Linux

19 December, 2009 09:09PM by Lior Kaplan

Mike Hommey

Iceweasel bug triaging

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 ? ;)

19 December, 2009 08:34PM by glandium

Dirk Eddelbuettel

Rcpp 0.7.0

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.

19 December, 2009 08:09PM

Michael Banck

19 Dec 2009

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.

19 December, 2009 02:40PM

Russell Coker

Shared Objects and Big Applications

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/

19 December, 2009 12:21PM by etbe

hackergotchi for avbidder+blog@fortytwo.ch

Adrian von Bidder

True Support

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.

19 December, 2009 11:13AM by Adrian von Bidder (nospam@example.com)

Robert Collins

Debianising with bzr-builddeb

Bzr build-deb is very nice, but it can be very tricky to get started. I recently did a fresh debianisation of a project that is in bzr upstream, and I thought I’d record the recipe to make it work (at least until the various bugs making it hard re fixed).

Assuming that the upstream uses bzr, it goes like this:

Start with a branch that is close to the code you want to Debianise. E.g. if the release was off trunk, 3 commits back: bzr branch trunk -r -3 debian
Debianise as normal: put the tarball with the right name in the parent dir, add a debian directory and fiddle until you build a package you’re happy with. Don’t commit while doing this.
Build a source package- debuild -S, or bzr builddeb -S
Revert your changes – bzr revert.
Import the dsc – bzr import-dsc ../*.dsc
Now, you may find that some dot files, such as .bzrignore have been discarded inappropriately (there is a bug open on this). If that happened, keep going. Otherwise, you’re done: you can now use merge-upstream on future upstream releases, and debcommit etc.
bzr uncommit
bzr revert .bzrignore (and any other files that you want to get back)
debcommit
All done, see point 6 for details.

Hope-this-helps

19 December, 2009 05:06AM

December 18, 2009

Bdale Garbee

TeleMetrum v0.2 Out for Quote

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.

18 December, 2009 11:31PM

Asheesh Laroia

Diversity in Free Software: South Asians as an example

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.)

18 December, 2009 09:25PM

Joey Hess

upstreams and packaging

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

18 December, 2009 06:44PM

Martin F. Krafft

KVM hosting and native IPv6

After several months of not-too-intensive searching for a KVM-hoster with native IPv6 connectivity, Steve hooked me up with a VPS at Bytemark, and I am very pleased. In addition to a properly virtualised KVM instance, I got access to a console server, which allows me to reset the machine, switch kernels, and log in “locally”. It’s exactly what I wanted, but it was hard to find, as everyone else seems to offer only Xen or Vservers, both of which are nearing end-of-life.

Thanks Steve, and Bytemark.

NP: Porcupine Tree: Up the Downstair

18 December, 2009 02:47PM

Robert Collins

Why upstreams should do distribution packaging

Software comes in many shapes and styles. One of the problems the author of software faces is distributing it to their users.

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. Currently the Debian and Ubuntu communities have a tendancy to actively discourage this by objecting when an upstream software author includes a debian/ directory in their shipped code. I don’t know if Redhat or Suse have similar concerns, but for the dpkg toolchain, the presence of an upstream debian directory can cause toolchain issues.

In this blog post, I hope to make a case that we should consider the toolchain issues bugs rather than just-the-way-it-is, or even features.

To start at the beginning, consider the difficulty of installing software: the harder it is to install a piece of software, the more important having it has to be for a user to jump through hoops to install it.

Thus projects which care about users will make it easy to install – and there is a spectrum of ease. At one end,

checkout from version control, install various build dependencies like autoconf, gcc and so on

through to

download and run this installer

Now, where some software authors get lucky, is when someone else makes it easy to install their software, they make binary packages, so that users can simply do

apt-get install product

Now some platforms like MacOSX and Microsoft Windows really do need an installer, but in the Unix world we generally have packaging systems that can track interdependencies between libraries, download needed dependencies automatically, perform uninstalls and so on. Binary packaging in a Linux distribution has numerous benefits including better management of security updates (because a binary package can sensibly use shared libraries that are not part of the LSB).

So given the above, its no surprise to me to see the following sort of discussion on #ubuntu-motu:

upstream> Hi, I want to package product.
developer> Hi, you should start by reading the packaging guide
(upstream is understandably daunted – the packaging guide is a substantial amount of information, but only a small fraction is needed to package any one product.)

or (less usefully)

upstream> Hi, I want to package product.
developer> If you want to contribute, you should start with existing bugs
upstream> But I want to package product.

Another conversation, which I think is very closely related is

developer> Argh, product has a debian dir, why do they do this to me?!

The reasons for this should be pretty obvious at this point:

Folk want to make their product easy to install and are not themselves DD’s, DM’s or MOTU’s.
So they package it privately – such as in a PPA, or their own archive.
When they package it, they naturally put the packaging rules in their source tree.

Now, why should we encourage this, rather than ask the upstream to delete their debian directory?

Because it lets us, distributors, share the packaging effort with the upstream.

Upstreams that are making packages will likely be doing this for betas, or even daily builds. As such they will find issues related to new binaries, libraries and so on well in advance of their actual release. And if we are building on their efforts, rather than discarding them, we can spend less time repeating what they did and more packaging other things.

We can also encourage the upstream to become a maintainer in the distro and do their own uploads: many upstreams will come to this on their own, but by working with them as they take their early steps we can make this more likely and an easier path.

18 December, 2009 12:18PM

Sandro Tosi

Remote Apache logging with syslog: is there anything better?

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:

[srv] prepare a machine to do the log server
[srv] open it's rsyslogd to receive messages on UDP (or TCP) port
[srv] log the selected facility.level to a log file
[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:

only 8 facilities for users custom log (local0-local7)
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.

18 December, 2009 11:31AM by Sandro Tosi (noreply@blogger.com)

Jurij Smakov

Slow boot

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.

18 December, 2009 09:09AM

Julian Andres Klode

The previous post

Well, it seems that several news sites (golem.de, pro-linux.de, linux-magazin.de, linux-magazine.com, ubuntu-user.de [the last ones all from the same publishing house]), especially German ones have picked up the last blog post with same false impressions.

First, they stated that I am planning an APT2 release for Christmas. They took the statement

[...] the internal branch has seen a lot of new code[...]. Most of the code will need to be reworked before it will be published, but I hope to have this completed until Christmas.

as a proof for this. But in the context of this paragraph, ‘publish’ was not meant in the term of publishing a release, but in the term of publishing the code (of the internal branch) in the public repository. The code is public now and lives in a ‘temp’ branch and will be reworked there for inclusion in the master branch.

Secondly, those news sites called me an Ubuntu developer. While I do contribute to Ubuntu, and am an Ubuntu Member, I am NOT an Ubuntu Developer, as I am NOT a member of the relevant ubuntu-dev team at launchpad.

Thirdly, those who stated that speed is a goal (mostly pro-linux, at least from my understanding): It is not, at least not now. It is just a coincidence caused by using a relational database. Furthermore, the test was not really fair, since the other package managers both provide more information than capt; information which has yet to be made accessible in APT2. It was just an initial conclusion that SQLite is quite fast.

Please note that APT2 is a free time project in development, and the programming language used is still in development as well; as well as some other reverse dependencies. I should also state that neither Debian nor Ubuntu have any plans to drop apt at the moment; and APT is still actively developed.

Posted in APT2

18 December, 2009 08:31AM by Julian Andres Klode

MJ Ray

Widgets, W3C and Wallies

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:

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

18 December, 2009 07:37AM by MJ Ray

Simon McVittie

Announcing gfcombinefs

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).

18 December, 2009 12:48AM

December 17, 2009

C.J. Adams-Collier

IRC logs for #ubuntu-us-wa

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.

17 December, 2009 07:55PM by C.J. Adams-Collier

Jon Dowland

shunit2

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.

17 December, 2009 04:02PM by Jon Dowland

Eugene V. Lyubimkin

a small script to satisfy build-dependencies from .dsc

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.

17 December, 2009 03:55PM

Stefano Zacchiroli

quotation of mine in 2009 free software timeline

last year DPL campaign strikes back

You might remember that last year I standed for DPL, ... and yeah, it didn't go well :-)

A funny event of last week is that LWN has taken a quotation of mine from the campaign, to become part of the Linux and free software timeline. The quotation is on last week LWN issue, and has been extracted from a reply of mine to a question posed by AJ on -vote.

Looking back, that quotation sounds a tad sad, but true nevertheless.

(The purpose of this post? Vanity, what else?)
... and thanks to Faidon for having spotted the quotation!

17 December, 2009 03:50PM

Vincent Sanders

What is it with embedded computing?

Last week I was given a development board for a system on chip (SoC) we were looking at using. All i had to do was ensure I could get a reasonable, supportable, bootloader and Linux kernel running on it.

Now I am a fairly competent engineer, I have worked with the ARM processors and SoC for many years. It should not therefor take me four days of almost continuous frustration to get a bootloader and kernel onto a system, but it has.

Firstly the system arrives and we look it over, the hardware design is not exactly elegant but seems like it will get the job done. That is at least a step up from several previous offerings which have been just plain broken. So I power it up and it boots into Fedora core 8, possibly not my first OS choice for a diskless system, but it does work.

Perhaps its worth mentioning that my experience with doing any Open Source development has caused me to have a severe aversion to software which is not upstream, especially kernels. The effort required to run your own patch series and keep it up to date is nothing short of Herculean.

Let us be honest, how many developers do you know who are talented enough to generate good code and patient enough to separately maintain it over a long period of time? I shall not belabor this point as others have repeatedly made it for me in much more eloquent ways. Lets us just say from my point of view. Upstream - good. Long term forks - bad.

With this in mind, the solutions Simtec develop are always with a view to our customers being able to simply download and use the standard upstream software wherever possible. Here is where the story stops being smooth and becomes a rant.

The system was running 2.6.22, one that was patched all which ways. "maybe they just shipped an old kernel" I thought. I opened the CD they provided and...oh, OK its just zips and tarballs of the binaries and source they used (actually that in itself is a minor miracle with a lot of vendors right now - see the almost continuous stream of copyright infringement litigation from the FSF) but sill stuck back in July 2007.

So i did teh normal thing, entered the URL printed on the outside of the box and went looking for the updates. No dice, just the same old stuff. So I contacted the company and recived the news that no there were no updates, that was what was published for the device, thats what I could have.

My initial reaction was of tired resignation...this would not be my first SoC port (probably around the fifth or sixth!) So I responded with cd linux-2.6;git checkout master;git pull and went to see what I could see. and lo and behold, there in the kernel, was full support for not only the SoC but for the other version of the very board I had.

Fortunately after mentioning this on IRC my giraffe loving friend. pointed me at the correct community git tree to find the tiny patch required to support my board.

So the vendor was not only shipping old code but actively dissuading customers from even looking for new stuff, which it turns out was mainline anyway! To add to this somewhere along the lines the company name on the box and contact information has changed and...well confusion reigned.

Right Plain sailing from here on? not quite...that would have been too easy. So you can build a mainline kernel...but you cannot boot it. you guessed it the bootloader they ship on the board is ancient, specifically a u-boot fork from December 2005. Having finally figured out how this was going to go, I went to the uboot repo, pulled the latest and built it for my target. And then I needed to upgrade the u-boot and joy of joys bricked the system.

Fortunately the system has a integrated FDTI serial/JTAG port so re-writing the flash should be as simple as running openOCD configured correctly. Of course this did not work...in the end I resorted to running their binary built versions from the CD (tarfile inside a zip inside a tarfile...whatever) and wrote their original image back to the board...which worked.

Long story short, next day I discover that i need a magic different uboot target (make u-boot.kwb for those that care) write this with the binary openocd build and...success
From then on its all been a bit anticlimactic and straightforward and I now have a system capable of starting a kernel over the network and a root fs on network, disc or flash.

My main complaint from all of this is what the hell are vendors doing shipping crap like this? Why do they all insist on taking a dreadful code drop from the SoC manufacturer when they first brought the part up and shipping that prototype junk until the part reaches the end of its life?!?

All the usual excuses about support etc. will come out, but seriously, you recive *no* support from vendors unless you pay for it and even then they will simply tell you whats on the CD is "it". Btw the diff for u-boot to support this board is larger than the original sources and the 2.6.22 is attacked with a 65MB diff which cannot be good.

The Open Source option is continuously innovating and improving, producing ever better software...but the embedded world seems to be forever stuck shipping crap. Is this just me? Does anyone have any solutions? Or am I stuck with this until I change profession?

17 December, 2009 02:02PM by Vincent Sanders (noreply@blogger.com)

MJ Ray

WordCamp UK, 17-18 July 2010 in Manchester

Advance notice of WordCamp UK 2010 on 17-18 July 2010 in Manchester. Ticket sales expected in early April 2010.

I voted for the Portsmouth bid, so of course Manchester won(!)

I’ve passed the event details to our co-op for consideration. Do you think we should go and if so why? If not, why not?

17 December, 2009 07:26AM by MJ Ray

Kees Cook

headache empathy

Run “gstreamer-properties“, click the “Video” tab, change Default Input Plugin to “Custom”, and add this Pipeline:

v4l2src ! ffmpegcolorspace ! vertigotv ! ffmpegcolorspace

Now when Empathy video-chatting with a friend, you can give them a headache!

Or give yourself a headache by trying it directly from the command line:

gst-launch v4l2src ! ffmpegcolorspace ! vertigotv ! ffmpegcolorspace ! xvimagesink

Feel free to replace “vertigotv” with any other or more of the video effects listed in “gst-inspect effectv“.

Here’s me with edgetv ! vertigotv:

Edge Vertigo

17 December, 2009 05:20AM by kees

December 16, 2009

Gintautas Miliauskas

Android apps

I've recently gotten myself an Android phone. The Android app market is not as mature as iPhone's App Store, but there is a lot of applications, and plenty of chaff to separate the wheat from. I found most of the apps I use by browsing "top Android apps" lists on the web, so I am putting up a similar list here in case someone finds it useful.

Everyday apps
- Astrid Task/Todo List - a great To-Do list app that integrates with Remember The Milk
- Quick Calendar - an "upcoming events" widget
- CardioTrainer - nice jogging app, records routes using GPS, integrates with music player
Language tools
- Thesaurus Free - a thesaurus
- Free Dictionary Org - reference dictionary
- QuickDic German Dictionary - an English-German-English dictionary
Media content
- Listen - an app to find audio content online
- Mother TED - search and view TED talks
- TuneWiki - music, song lyrics
Games
- Lumbricidae - guide a worm using your accelerometer
- Flying High - plane flying (also accelerometer-based)
- miniMatcher - memory game
- Iconic Memory - another memory game
Cool apps
- Phonalyzr - pretty phone call (and SMS) stats
- Shazam - identify a song by recording a short snippet; possibly one of the coolest apps available
- SnapTell - look up product information by scanning a barcode (or even by snapping a photo!)
- Backgrounds - background images
- Google Sky Map - shows constellations
- Layar Reality Browser 3.0 - a fancy-looking Augmented Reality app
Music
- Sonorox - tune composition for everyone (the pentatonic scale is great, isn't it?)
- Loops! Lite - another music composition app
- Tuner - gStrings - a guitar tuner
Miscellaneous
- Task Manager - a process monitor utility, useful for checking up on app resource usage
- Currency - a currency converter
- Sleep Logger - a very simple, but useful app for tracking your sleep habits

16 December, 2009 08:56PM by Gintautas Miliauskas (noreply@blogger.com)

Martin Meredith

Only one squirrel can say it as it is…

16 December, 2009 04:42PM by Mez

Daniel Baumann

Syslinux Themes for Debian

10 days ago, I uploaded syslinux-themes-debian. It is sitting in the NEW queue ever since, and aparently I cannot rely on it being accepted anytime soon (it can be installed from the repository mentioned on the maintainers homepage, though).

However, while being still a first working version only that needs some improvements (especially until it could be used as a generic ressource for any other tool to make use of it, like live-helper or debian-cd, eventually), here's a screenshot from the squeeze theme, credits and a big thanks for the awesome graphics to Agnieszka Czajkowska.

Syslinux Theme Debian Squeeze

16 December, 2009 02:52PM

Holger Levsen

Debian Wine soon to be sold out?

In case you want to buy some (more) bottles of wine made for DebConf9, you need to hurry up. Also a bit more hurry is appropriate if you want it to be delivered til XMas :-)

(Picture credit belongs to Chris.)

I'm planing another (offline) sale at the 26C3 congress in Berlin at the end of the year, which might or might not work out. If it does, the number of bottles available for online ordering will be reduced significantly, and basically I'm only waiting for some details to be finalized for announcing this for real, so hurry up and mail order now - unless you have enough Debian wine bottles at home already :-)

Information how to order is available in our wiki at DebianWine. The profit made will be given to DebConf9, and as that has been dealt with finacially successfully, it will be given to DebConf10!

16 December, 2009 01:50PM

Wouter Verhelst

Grrr

struct {
	char str[4];
	char sc1;
	char str2[3];
	char sc2;
} foo __attribute__((packed));

snprintf(foo.str, 5, "%04X", data);
foo.sc1 = ';';
snprintf(foo.str2, 4, "%03X", otherdata);
foo.sc2 = ';';

Yes, I know that both snprintf() calls in the above snippet will overflow their immediate buffer. Yet this code is safe; the network protocol for which this code is written does not actually need nor expect NUL bytes; instead, it wants semicolons. I could of course use a "char foo[9]" rather than a struct as above, but I find this to be slightly more convenient than to count offsets.

However, this code does not work with glibc, because the buffer overflow detection kicks in.

Solution:

char buf[5];

snprintf(buf, 5, "%04X", data);
memcpy(foo.str, buf, 4);

In other words: add a stupid and useless memcpy, because someone thinks they're smarter than me. Stupid morons.

16 December, 2009 01:46PM by Wouter Verhelst (w@uter.be)

Pablo Lorenzzoni

Debian-RS and Vincent Danjean

The day before yesterday I learned that a fellow Debian Developer was visiting Porto Alegre Federal University to do some work on Parallel Computing: Vincent Danjean. People from local user group organized a last minute get-together at Cavanhas (that served as last meeting of the year) and we had the most pleasant time. Guaraldo registered the moment with his cellphone camera:

Vincent is flying back to France today or tomorrow. Hope he had a great time in Porto Alegre and have a safe trip back home.

16 December, 2009 12:31PM by spectra

MJ Ray

Thunderbird 3 Introduces Reply-To List

I’ve kept a page of email clients that support mailing lists for a while and it’s been a bit disappointing that I couldn’t suggest Mozilla Thunderbird or its freer derivatives (IceDove?) as good clients. They work fine in most other ways and it’s nice having something good that we can suggest to users on MacOS and Windows, but there was a long-standing bug requesting support for the List-Post header.

In an email discussion on ALUG’s main list, a couple of people mentioned that Thunderbird 3 was released last week with a working “reply to list” command. This is excellent news, removing the need for the Reply To List add-on.

I hope we’ll see it in IceDove soon. Fantastic work. I wish it was in the release notes so we’d spotted it sooner. Now there is even less excuse for MUNGing the Reply-To header, even on lists where Windows users are present.

16 December, 2009 06:46AM by MJ Ray

Raphael Geissert

what could you tell about spammers after receiving one billion messages?

This is a question that Project Honey Pot's report answers.

They have released a report of the analysis of not only spam messages, but also of the harvesters behind spam.
Available with a simple overview the complete report provides some rather interesting details.

Do spammers take holidays?
The volume of spam drops approximately 21% on Christmas Day and 32% on New Year's Day. Saturday is the quietest day of the week.

And for those sending mails to public mailing lists, the BTS, etc:

How much harm does a harvester visiting my site do?
You can expect to receive 869 spam email messages every time a harvester picks up your email address from a website online.

The interesting bits are really worth the five-ten minutes it takes to read the complete report, enjoy it (and yay, it is CC-BY).

16 December, 2009 03:04AM by Raphael

December 15, 2009

John Goerzen

Review: A Christmas Carol

I guess you can say that A Christmas Carol by Charles Dickens has been a success. It was published in 1843 and has never been out of print since then. It’s spawned all manner of plays, films, adaptations, and spoofs. It’s been adapted at least twice by Disney, once featuring Mickey Mouse and another time featuring Jim Carey. We’re almost inundated with the story — I’m not sure how many ways I’ve seen it. Yet I had never read the original story by Dickens until just now.

And I must say, what a treat it was. Despite knowing the plot in advance, it was a very good read. The 19th century London setting was done well. It wasn’t some idealized London as is often portrayed in film adaptations. It had depth, as did the characters. Dickens’ Scrooge had a troubled childhood, the son of poor and apparently abusive parents. He turned to business, with which he was successful. Along the way, he lost sight of family, and really of his humanity in general, striving to be a richer and more successful businessman at the cost of all else.

How apropos this story is for us in the 21st century. Our large banks define success in terms of profits made for their shareholders, while adding more gotchas to the terms of the credit cards held by their customers. Our governments play geopolitical games over weapons, oil, and gas, while unwilling to sacrifice anything to prevent a climate disaster. Our politicians, even in the season of Christmas, turn a blind eye and a cold heart to the suffering of those that can’t afford health care for naught but political reasons, rather than trying their hardest to make a plan that will help them reality as soon as possible.

And what of us, the citizens of the 21st century? We consume ever flashier cars, houses, computers, and cellphones with data plans, while poverty intensifies across the globe in this economic downturn.

Well, count me among those many inspired and reminded by Dickens to be a more empathetic person, to remember how good even many of the poor in the West have it compared to other parts of the world, and to try to do more for others.

And that, perhaps, is part of the genius of Dickens. He inspired a complete change of how people looked at Christmas in his time. And his work is no less relevant today; perhaps it hits even closer to home these days. He invites us to carefully consider the question: what does it mean to achieve success in life? And he deftly illustrates that “wealth” is wrong answer. Here’s hoping that many others will also learn a small bit about life from Dickens.

How to find it:

A Christmas Carol is available for free from Project Gutenberg for reading online, printing, or reading on an ebook reader such as the Kindle.

Be careful when buying printed editions. Many have been abridged or “improved for a modern audience”, and thus lose a lot of the quality of the original. I found at least one edition that looks true to the original; I’m sure there are others.

[This review also posted to Goodreads]

15 December, 2009 11:19PM by John Goerzen

Tollef Fog Heen

N900 – first impressions

Collabora was kind enough to buy N900s for all its employees. Yay! I got mine on Friday and has been playing around with it quite a bit. It's very shiny and the user experience is a lot better than the N810. There are a few graphical glitches, it seems it's XDamage damaging a bit of a window and it's just not quick enough to repaint. Not a problem, and it has far fewer instances of just hanging for half a second which my iPhone has. That is, it hasn't had any of those yet.

The screen is good, but resistive. Takes a short while to get used to when you're used to capacative, but it's not a problem at all. The keyboard is good, but I need to map something as the compose key. Having US/UK key caps and using the Norwegian layout is a bit confusing. Not really the fault of the device though.

The web browser is generally quite good. The gestures take a bit of time to get used to, but they're not hard as such. Some of the default "applications" are implemented as just links to the web pages of services like Twitter, which is a bit silly as you don't even get a version that's optimised for the N900. They're not useless, but they are absolutely nowhere near a real application. Also, the "Store" (Ovi Store) application/web page says "coming soon", which is quite odd.

I'm not sure if I can change the selection of applications on the default application list, but modifying the desktop is easy. There seems to be few themes and background images available so far, at least in anything resembling official repositories. Hopefully this will improve over time.

So far, I haven't actually written any code for the N900. I have some applications I want to write, mostly widget-style apps like "when does the next bus home leave from a bus stop close to me and where is the bus stop", but also some other ones.

Battery life is not great. It almost did 48 hours today with a bit of use underway, and I did charge it before it ran completely out, but when I'm used to closer to a week, it's not that good. Camera seems good and is quite fast, I think it took less than five seconds from opening the camera shutter until I had taken a picture. Shutter delay is quite bad at about a third or half a second, but this is a mobile phone (or mobile computer, as Nokia likes to call it) and not a DSLR, so I'm quite happy with it.

As a phone, it seems fine so far. I can make calls and accept calls and there's no noticeable problems with it. It also functions as a modem/DUN over bluetooth, which is quite useful.

Build quality seems good, there's a good feeling when sliding the keyboard in and out, but only time will tell how good it actually is.

So far, I'm happy with it, it's a big step up from my previous UK phone (which is a Nokia E70; my iPhone is a 2G phone so I can't use it here with the provider I'm using). Hopefully I'll post more happy stories about it in the days to come.

15 December, 2009 05:53PM

Russell Coker

Play Machine Online Again

I have returned from the US and my SE Linux Play Machine [1] is online again.

It was unfortunate that I forgot to pack one of my Play machine shirts, I ended up attending a meeting of the SDForum [2] on the topic of Cloud Security (it was a joint meeting of the Cloud Services and Security SIGs) and it would have been good to have been wearing a root password.

15 December, 2009 02:00AM by etbe

December 14, 2009

Vincent Sanders

Two pussies, one box

Our household contains two felis catus. These evil creatures (sorry I repeat myself, I already mentioned they were cats) are not sweet kittens, they are grumpy old animals who spend the majority of their lives sleeping indoors and rarely venturing out.

Historically they have had free reign of the house and slept wherever it suited them but with the arrival of the children they were confined to the lower half of the house and provided simple cardboard boxes in which they can reside completely undisturbed.

All well and good you might say and indeed this has produced happy cats for the last eight years. however I recently caused a great deal of discord in the household by providing new boxes never imagining this could possibly cause as much trouble as it has. Currently the two of them are attempting to occupy a single box and win some form of passive aggressive fight for occupancy.

This has been going on for a month now and shows no sign of easing. I do wonder what I need to do to aleviate this situation before it results in a full blown outbreak of evil. Any ideas?

14 December, 2009 06:53PM by Vincent Sanders (noreply@blogger.com)

Jo Shields

FOSDEM 2010

I will be at FOSDEM in February next year. It should hopefully be awesome. Anyone who packages Mono on any distro should definitely come, or does any Mono-related stuff in general, since not only will I be there, but the fabulous Mirco Bauer too – and perhaps other wonderful people.

Definitely a fine use of your moneycash.

14 December, 2009 02:13PM by directhex

Russell Coker

Nagios and SSL in Debian

I was doing some work on NRPE (the Nagios Remote Plugin Executor) and I noticed bug report #547092 [1] which concerns the fact that the default configuration uses the same SSL certificate for all Debian servers and provides a patch to fix the problem. After building the patched package I followed the advice of the DebianAdministration.org article on creating self-signed SSL certificates [2].

cert_file=/etc/ssl/certs/FOO-cert.pem
privatekey_file=/etc/ssl/private/FOO-key.pem
cacert_file=/etc/ssl/certs/cacert.pem

Then I added the above lines to /etc/nagios/nrpe.cfg to instruct the nrpe to use the certificates.

For the Nagios server I had the problem that most of the systems I monitor run old versions of NRPE while only a few are recent Debian systems that allow me to easily install a new SSL checking nrpe. So I installed the following script as /usr/lib/nagios/plugins/check_nrpe to run either the old or the new check_nrpe:

#!/bin/sh -e
if echo $2 | egrep -q server0\|server2\|mail ; then
/usr/local/sbin/check_nrpe -C /etc/cert/cert.pem -k /etc/cert/key.pem -r /etc/cert/cacert.pem $*
else
/usr/lib/nagios/plugins/check_nrpe.orig $*
fi

The reason I started working on Nagios was to try and solve bug #560002 [3] which I filed. The bug concerns the fact that applications such as mailq which are run as part of Nagios checks were inheriting a TCP socket file handle from the nrpe. SE Linux prevents such file handles from being inherited, but it does mean that I get audit messages (and this is not a good case for a dontaudit rule).

Update:
One thing I forgot to mention is that the SSL key checking requires that the server common name used in the SSL certificate of the nrpe system matches the name that is used by the check_nrpe program. So if you check by IP address then you need to use the IP address in the certificate name – which is rather ugly. So I have moved to putting the hostname of each server in /etc/hosts on the NAGIOS system and using the hostname in the SSL certificate. This required using $HOSTNAME$ instead of $HOSTADDRESS$ in the NAGIOS configuration (thanks to John Slee for a tip in that regard).

Update2:
I removed some printf debugging from the script. It seems that I included a pre-production version of the script in the first version of this blog post.

14 December, 2009 01:30PM by etbe

David Welton

File Selector for Java ME

I recently did some work to make Hecl read files, which also means that it can execute Hecl scripts from the phone's memory. This is especially important for environments like Blackberry, where we will be distributing a signed version of the Hecl application. To create your own Hecl applications, instead of simply replacing the script in the .jar file, you can point to a script on the device's file system. This is also available for normal Java ME phones, but unfortunately, for an open source project, the cost of a code signing certificate are prohibitive (on Blackberry, it's only $20, so I bought one with my own money).

In any case, as part of this effort, I developed a very simple 'file browser', which is used in Hecl to select a script to execute.

The results are, like all of Hecl, available under an Apache license, which means that you can use it pretty much wherever you want:

http://github.com/davidw/hecl/blob/master/files/org/hecl/files/FileFinder.java

http://github.com/davidw/hecl/blob/master/files/org/hecl/files/FileFinderCallback.java

Of course, if you spot any ways to improve it or fix problems with it, I'd appreciate it if you sent patches back.

14 December, 2009 12:31PM by David N. Welton

Phil Hands

arduino for the java challenged

Having excitedly bought an Arduino from the nice folks at tuxbrain.com while they were at DebConf9, I was then a little deflated to discover (while attending the UKUUG's Arduino Workshop in August), that the IDE is written in Java. While I can see that the authors might perceive this as the easiest way to provide cross-platform pointy-clicky-ness, JREs have a half-life of about an hour on my systems.

Anyway, I fought with Java to show willing, until I'd determined that the IDE didn't seem to be happy running under xmonad (rendering menus so that they were unclickable) and gave up -- spending the rest of the tutorial proving to myself that I could compile and upload C code for the little beastie, but failing to compile Arduino sketches on the command line.

Ever since, I've been meaning to work out the required CLI incantations, and finally made time over the weekend. The incantations turn out to be rather simple, if not very obvious, so I thought the world could benefit from a package that encapsulates the required knowledge.

I've pared the source tree down to the c++ code and some examples and tweaked the Makefile so that it'll do it's work out of tree, referring to the files that the package installs for you, which allows you to apt-get install aurduino-core and then cut&paste a few lines from the contained README.Debian in order to get an LED blinking for the first time.

The resulting git repo is now on Alioth. The binary-indep package it produces I've called arduino-core -- hopefully I've left enough room for any fan of the Java IDE to shove that back into the upstream branch and add packages for the full IDE, and maybe throwing in another package for the GTK IDE that's out there.

I'm very mildly concerned by the fact that Arduino is a trademark of the Arduino Team, but that trademark is for the circuits, not the software, so this is probably irrelevant. If you think I should care enough to rename the package to freeduino, say, please get in touch.

Anyway, if you have an Arduino (or similar) please grab a copy and test it.

14 December, 2009 10:58AM

Stefano Zacchiroli

RC bugs of the week - week 14

RCBW - week #14

Here are ~~this~~last week squashes, by yours truly:

07/12/2009 bug #555636 - fsprotect - sponsor upload by Stefanos Harhalakis
08/12/2009 bug #518433 - libxalan2-java - lower severity (evidence that affects other packages is missing)
09/12/2009 bug #559720 - fieldslib - support bytecode-only build (fix FTBFS on s390 and other)
10/12/2009 bug #560552 - gtkmathview - fix unapplicable patch that induced FTBFS
11/12/2009 bug #550096 - memtest86+ - add missing conflicts on old grub (sponsor Iustin Pop's upload)
12/12/2009 bug #553292 - memtest86+ - switch from read to debconf in postinst (sponsor Iustin Pop's upload)
13/12/2009 bug #553291 - memtest86 - switch from read to debconf in postinst (sponsor Iustin Pop's upload)

Some highlights:

Luk's list strikes back (even though I've kept one in the pipeline for this week)
I had to fix a couple packages of mine which got RC buggy: fieldslib (which was failing on non-native OCaml archs) and gtkmathview (which was in need of love since some time now)
several of the above fixes are sponsored uploads and I'm particularly happy about the memtest's ones, as they've been contributed by my first NM ever: keep up the good work, Iustin!

14 December, 2009 08:46AM

Ondřej Čertík

ESCO 2010 conference

An interesting conference 2nd European Seminar on Coupled Problems (ESCO) will be held on June 28 — July 2, 2010 in Pilsen, Czech Republic.
Among the topics are solving PDEs and applications and using Python for scientific computing. In particular, Gaël Varoquaux is the keynote speaker.

Unfortunately, it was later announced that the SciPy 2010 conference is going to be at the same time, which is really unfortunate. But here are some reasons why you should consider going to ESCO 2010 instead:

If you like numerical calculations (finite elements, differences, volumes, ...) and solving partial differential equations and other problems and also programming in Python, together with C/C++ or Fortran, you will have a chance to meet some of the top people in the field. SciPy conference usually has people who solve PDEs (e.g. SciPy 09 had about 6), but ESCO 2010 will have about 60. So ESCO wins.

Robert Cimrman, who you probably know from the scipy and numpy mailinglists, also the author of the sfepy FEM package in Python, lives in Pilsen, so he'll gladly show you some good Pilsen pubs. SciPy 2010 is going to be in Austin and while Austin has cool pubs too, I must be fair and I liked that (I was there at the Sage 08 days), but it's just not comparable, the beer is better in Pilsen, it's a historic city and there are more pubs.

Pilsen is close to Prague, so you will have the chance to visit it. You should walk in the old town, have couple beers etc. Here you can see some photos that Gaël took when we met in Prauge. Again, this is incomparable with Austin.

It is held in the Pilsner Urquell Brewery. When Pavel Šolín announced that at the SciPy 09 conference, Jarrod asked "Ah, in a beer pub?". So let me be clear. The word pilsner (type of the beer) is coming from the Czech city Pilsen (Plzeň in Czech). Pilsner Urquell is not some beer pub (e.g. even Reno where I live now has a beer pub), it's The Brewery. Austin is a cool place (and Texas steaks are really good), but as you can see now, it absolutely cannot compete with Pilsen.

If you have time, I can fully recommend to go to ESCO 2010.

14 December, 2009 04:49AM by Ondřej Čertík (noreply@blogger.com)

Kumar Appaiah

For Hindi Debian users

(English translation below. Indian Debian community, please spread the word!)

डेबियन का उपयोग करने वाले मेरे साथियों! शायद आपको पता नहीं, पर डेबियन के कई अंश कई भारतीय भाषाओं में उपलब्ध है, और KDE, GNOME और अन्य कई प्रोग्राम पूरी तरह हिंदी में उपलब्ध हैं. यह कई लोगों की स्वेच्छापूर्वक सहयोग द्वारा ही संभव हो पाया है. इसमें डेबियन संस्थापक (Debian Installer) के वाक्यों का अनुवाद Lenny से लेकर अब तक मैं करता आ रहा हूँ, और आगे भी करता रहूँगा. पर सब की तरह मेरा समय, और हिंदी में तकनीकी शब्दों का मेरा ज्ञान, दोनों सीमित हैं. इसलिए, मैं डेबियन का उपयोग करने वाले मेरे साथियों से अनुरोध करता हूँ की, अगर आपके पास समय हो, तो कृपया डेबियन संस्थापक के वाक्यों के अनुवाद में मेरी सहायता करें. ऐसा करने से आप प्रसिद्ध होने के साथ साथ डेबियन के हिंदी उपयोगकर्ताओं की कृतज्ञता भी प्राप्त कर सकेंगे!

अनुवाद में हाथ बंटाने के लिए हिंदी में प्रवीण होने की आवश्यकता नहीं है; केवल हिंदी का व्यवहारिक ज्ञान और ज़रा समय देना हमारे लिए काफी लाभदायक होगा.

अधिक जानकारी के लिए संपर्क कीजिये: akumar@डेबियन.ओर्ग (अंग्रेजी में) ;-)

धन्यवाद!

Translation

Fellow Debian users (who know Hindi)! Maybe you aren't aware yet, but several parts of Debian have been localized and are available in several Indian languages, and KDE and GNOME and several programs are available natively in those languages. This has been possible only due to dedicated volunteers spending time in translating the programs. I have been translating the strings in the Debian Installer to Hindi, since Lenny, and will continue with the translations. But like others, I am short on both time, and my knowledge of technical Hindi words and phrases is limited. So, I'd request fellow users to chip in with some translations to the Debian Installer strings, if they have the time. That way, not only will you earn fame and glory, you'll also earn the gratitude of the Hindi Debian user community.

You don't need to be an expert in the language and grammar to help out with the translations. All you need is some working Hindi knowledge and a bit of time.

For more information, email me at akumar followed by debian.org

Thank you!

14 December, 2009 03:56AM by Kumar Appaiah (kumanna)

Joey Hess

two films

I've been watching some good films recently. Two I especially liked.

Goodbye Solo starts in Winston-Salem and ends up at Blowing Rock. Both settings, as well as the taxi in between, are very familiar. The characters could easily be people I've met.

Tulpan is set in a steppe in Kazakhstan. The desert and dust devils mostly reminded me of Mars. Particularly of this amazing shot taken by the Spirit rover.

dust devils on Mars!

Still, I felt so much more at home in Tulpan. Kept pausing it to check out how the family had their yurt set up and furnished, and watched their very real-seeming life unfold, right down to the lambing scene. While Solo took the very familiar, and confounded expectations and biases at every step.

They're both fine films, from directors I want to see more of. I've seen Ramin Bahrani's work before Solo, and especially liked Man Push Cart. Don't know if I will ever find any of Sergei Dvortsevoy's earlier films.

14 December, 2009 02:10AM

December 20, 2009

RCBW - week #15

Manually logging an error to syslog

Forcing a logcheck run

Finding the broken rule file

Solution to my problem

December 19, 2009

December 18, 2009

Why care about diversity?

Changing the balance

What success looks like

tools

December 17, 2009

last year DPL campaign strikes back

December 16, 2009

December 15, 2009

December 14, 2009

RCBW - week #14

Translation

Planet Debian

Search

Planetarium

Hidden Feeds

Subscriptions