lunatechian (lunatech-ian)

When doing an apt-get upgrade on my Debian (Lenny) box yesterday I received this message

Since release 150, udev requires that support for the CONFIG_SYSFS_DEPRECATED feature is disabled in the running kernel. Please upgrade your kernel before or while upgrading udev.

This was holding back the upgrade of all the packages. Looked around a bit and it seems that the solution for this problem is to let apt know that we do not want to upgrade the udev package. The way to do this is echo "udev hold"|dpkg --set-selections and then run apt-get upgrade

Linux User Group, Bangalore have a meetup at the ThoughtWorks office on Saturday 21st February 2009, 4:30 PM onwards. The details of the meeting are here. There are 2 talks lined up- "Introduction to the Android Platform" and "Device Mapper - How it works and why you should be using it". And there will be a key signing party as well.

Go, check it out and help revive the LUG meetings at Bangalore.

I tried installing linux on my SO's (significant other) laptop today. WHAT IS WRONG WITH UBUNTU!! It takes ages to load up and the install process is resource intensive enough to make the laptop totally unresponsive. Finally installed Fedora and I am not happy with it. I will install debian for her, once I find out where to get blank CD here.

I saw this mail in one of the mailing lists I am on and thought it might be useful to a wider audience. This reply was given by Ben Finney

   I have some ambitious plans for enhancing the module, but I feel
   that it won't be practical to do it in the current conditions. I
   tried to soft-talk the maintainer into giving me repository access,
   but then the conversation got diverted into applying my latest
   patch, which he said he'd like to perform the next day. He didn't
   and it's been at least two weeks since then.

Since you talk about asking for “commit access”, I presume it's in an old-school centralised-only VCS. I'll assume Subversion.

What are your thoughts about a situation like this?

Use a distributed VCS to track your changes. I prefer Bazaar, so I'll discuss that below.

• Use Debian GNU/Linux, ‘lenny’ or later.
• Install the necessary packages: $ sudo aptitude install bzr bzrtools bzr-svn svn
• Get a local Bazaar checkout of the upstream Subversion branch so you can track upstream's changes discretely and easily: $ bzr checkout svn+ssh://vcs.example.org/foo/trunk/ foo.trunk/
• Bazaar uses the ‘bzr-svn’ plugin to work with Subversion repositories. It has its foibles, especially with writing to Subversion repositories; but for tracking an upstream Subversion repository against your Bazaar-managed branches, it's excellent.
• Branch from upstream so you can track your changes: $ bzr branch foo.trunk/ foo.interesting-new-feature/
• Work on your interesting new feature, committing often:

    $ cd foo.interesting-new-feature/
    $ emacs spam.py  # hack hack hack
    $ make test  # or however you run your full test suite
    $ bzr commit --message "One-line description"

• When upstream has new revisions in their repository, update your checkout:

    $ cd foo.trunk/
    $ bzr update

• When you want to send a patch of your current work against upstream, generate a Bazaar “merge directive” (a patch bundle):

    $ cd foo.interesting-new-feature/
    $ bzr send --output ../foo.interesting-new-feature.patch --no-bundle

• This makes a patch against the parent of the current branch (by default, since no other branch is specified), which is the ?foo.trunk/? branch you originally branched from. The --no-bundle option turns off the ?patch bundle? blob, which would be useful to a Bazaar-using remote user to merge the resulting patch and have identical revisions to you. Since you'll be sending it to a Subversion user, that blob won't be useful to them so we disable it.
• Send the ‘foo.interesting-new-feature.patch’ file to upstream attached to an email message that explains what the changes are.

The Bazaar documentation, both online at <http://bazaar-vcs.org/> and in the bzr help foo commands, is comprehensive and should fill the many gaps I've no doubt left from the above explanation.

I was just reading a very interesting article from Jeremy Allison of the samba team called The Land of "Nothing for free". A very interesting quote

My panel was rather uncontroversial, Microsoft, Bruce Perens and myself being on our best behavior. The only sparks that flew where when Microsoft made it abundantly clear that they would use their patent portfolio to prevent the spread of GPL software. Section seven of the GPL (the implicit patent grant of the license) now looks like the most prescient writing Richard Stallman has ever done. If you're not familiar with it I'd suggest you read it and understand why using the GPL to protect your Free Software is so important.

The article is old, but do check it out.

Thanks to egrep for linguists for giving this nice and clear example of using egrep.

There are different ways to match both star and stars within a single search pattern. The most straightforward way might be to tell egrep to look for either the string star or the string stars with the help of a disjunction, expressed with the vertical bar, |. This time the search pattern has to be quoted in order for the program to know where the search pattern starts and ends

    $ egrep -w 'star|stars' sonnets.txt
    Not from the stars do I my judgement pluck,
    And constant stars in them I read such art
    Whereon the stars in secret influence comment.
    Let those who are in favour with their stars,
    Till whatsoever star that guides my moving,

If you have been using Linux, I think you must have been frusturated with the lack of good fonts when using Emacs. It gets very hard to distinguish between "l" (the letter l) and 1 (number 1) and between comma and semicolon when programming or examining large amount of code.

The Bitstream Inc have done an excellent work in producing and relesaing under a very liberal license, the bitstream-vera fonts. These fonts are really beautiful and easy to read. To use these fonts with your emacs, just add this line to your ~/.Xdefaults file

 Emacs*font: -bitstream-bitstream vera sans mono-medium-r-*--*-100-*--*--*- 

Of course, you need to have the bitstream-vera fonts installed on your Linux box