Emacs splash-screen

So one fine day, I grew tired of the emacs splash-screen. You try to edit a file and emacs shows its splash-screen instead of the file contents and then you have to "Press any key to continue". So one day it got on my nerves and I decided that if I don't find a way to disable it, I am going to switch to vi. But, how can an editor as customisable as emacs NOT have an option to disable the splashscreen? Ofcourse it does! and it was the first result on my google search! (probably there are just too many people in this world irritated by the splashscreen, why doesn't emacs just do away with it?)

Simply add this line to your .emacs file:

(setq inhibit-splash-screen t)

yum plug-in : Presto

I have ranted about Presto in my earlier blogpost. Yum's fedora maintainers implemented this really cool idea of maintaining difference between binary packages instead of the binary packages themselves. It would help a lot to push out updates. I was sceptical at first about the amount of savings it would result in (because obviously binary difference is something very complicated). I expected a 20-30% saving. Although people kept reporting numbers of upto 90%.

Today, I decided it was time to "yum update" my machine. (crashing pidgin, crashing rhythmbox, bad font rendering). So, I ran yum update. It showed me a total download size of 876MB (i.e. the total size without presto.. since, presto is new and under beta.. its integration with yum is only perfunctory). So, I dozed off. Today I check my internet usage and guess what, the total usage yesterday night was less than 100MB. Awesome! (Usually, presto shows the difference. It prints out a line saying "This is actual download size and this was download size with presto". But, as I dozed off, the line went off the terminal limit).
Anyway, it is infact 90% savings! that is so awesome! Now I can "yum update" even during the day :D. No need to wait for the night free time.

Goooo fedora!!!!!

Linux sound level too low?

After having (finally) upgraded Fedora-11, I found it pretty annoying that the sound level was wayy too low. I mean, even with speaker volume set to full, system volume set to full and application volume set to full (not to forget pulseaudio volume .. which is another layer between the app and the system), the sound levels were only just enough for me to watch a movie without missing out a dialog. WTH! I have awesome speakers and they should ideally crack my windows. But here, even full volume was just barely enough. It hurt my ego (:P).

On Windows, the full volume is a real window-cracker. What is the problem with Linux then? (I could replicate the same issue on Ubuntu 9.04 too.. that should explain why I went for generic "Linux" and NOT "fedora"). Then I found this bug filed in the fedora bugzilla which made things clearer (actually, they didn't). Don't bother to read, it went swooosh over my head. The only thing that stuck was - How to solve the problem.

Here it is:
Make sure you have the package "alsa-utils" installed.

For fedora:
$ sudo yum install alsa-utils

For Ubuntu:
$ sudo apt-get install alsa-utils

Then, run
$ alsamixer -c 0
and increase the master volume beyond green area to the red area. (I understand that the red area implies increased noise, but I didn't really notice much of a difference with a slightly less than maximum setting. Even with max master volume, there is only a slightly noticeable noise)

I don't understand why this control is hidden away in such a manner. What is the whole point? Why not export a GUI for it? Weird. Probably they'll fix it in fedora 12. There's been a lot of work in the sound area in the last 6 months. There are going to be some bugs afterall. Anyway, this healed my ego :P. Linux sound is at-par with any other sound system! It makes me happy!

Emacs: linux-c-mode and Line numbers

Tired of the slow ssh access to one of the servers located outside India, I finally figured it was time to start playing with emacs to reduce the number of keystrokes needed.

First on, I wanted the linux-c-mode enabled *by default* whenever I open a file whose extension is ".c" (Yeah Yeah, I know extensions are meaningless for Linux.. but emacs is intelligent :) ). For all the other type of files, linux-c-mode should be OFF, because it will mess-up their indentation.
Second, line numbers should be displayed on the left-hand-side panel of each file I open. Then to go a particular line I just "M-g g". Simple.
Third, All this should be accessible to my user account as well as root user.

So, I edit the ~/.emacs file (create if not already present) like this (for the first goal):
(defun linux-c-mode ()
  "C mode with adjusted defaults for use with the Linux kernel."
  (interactive)
  (c-mode)
  (c-set-style "K&R")
  (setq tab-width 8)
  (setq indent-tabs-mode t)
  (setq c-basic-offset 8))

(add-to-list 'auto-mode-alist '("\\.c$" . linux-c-mode))


The first chunk defines the linux-c-mode (from Documentation/CodingStyle) and the last line enables it by default ONLY for *.c files. Simple!

For the second part, I got a script linum.el from google (Vedang says it has been integrated into emacs)
You can find the script here: http://jitesh.1337.googlepages.com/linum.el
Drop this script at /usr/share/emacs/site-lisp/

There's a problem with this script. It doesn't print a space after the line number. Sad!
Here is a patch I wrote to fix it: http://jitesh.1337.googlepages.com/linum.el.patch


Now I want to display line numbers for EACH file I open in emacs. So, I add the following lines in the .emacs file:
(require 'linum)
(global-linum-mode 1)

(First line is needed to autoload linum.el. The second line enables it by default)
To toggle the linum mode, use "M-x linum-mode"
Simple!


Finally, I wanted to give access to root user too.
A simple solution would be to make a symlink/hardlink from /root/.emacs to /home/jitesh/.emacs.
However, I wasn't too concerned about the other users on the system :) .So, I simply copied to .emacs file to /usr/share/emacs/site-lisp/site-start.d/ and renamed it as myinit.pl. So, now, these things get enabled by default for *all* users.

Now that everything is setup (and steps documented via this blog), let me go back to coding peacefully in emacs!

Upgrading to Fedora-11 (Leonidas)

Finally I got my hands on the brand new Fedora release. Fedora-11 (Leonidas). As I had a sneek-peak into the development process this time around (work reasons), I was pretty excited to upgrade to this new version. There are a couple of nice features in Fedora-11 that makes it awesome.
1) Presto: Delta-RPMs. If you are updating your system, yum now fetches only the *change* between two versions instead of pulling in the new version entirely. Savings of 60-70% of bandwidth have been reported.

2) PackageKit: Makes installation of new packages and plug-ins very easy and user-friendly.

Time for installation.
So, I booted into F10 and set the system up for the normal upgrade method that I use. Which is:
1) Insert the DVD.
2) Make a yum repo which points to the DVD.
3) Issue a "yum update"
4) Watch a movie while your system upgrades.

However, this time I decide to be a good boy and read the fedora docs first to see whether it had to say anything about upgrades. Turns out it was a good decision. Apparently, there is a bug which makes such an upgrade impossible and leads to a possibly "unusable system". Whew! close shave!

So, why the hell did they release F-11 when a method of upgrade was broken? Well, there were vibrant discussions in the fedora community over this bug and the final decision was: This upgrade method is not "recommended" and "supported" and hence, it isn't a F-11 blocker bug :(. Sigh!

So, guess I'll have to follow the "recommended and supported" method. Boot from DVD and choose "upgrade". I'll have to stare at the screen for an hour while the system upgrades :)
Looks like I'll wait for a respin which contains a fix.
(/me adds himself to the CC list for the bug)

Another caveat is that the rpm format has been changed in Fedora-11 to make it more secure. This makes upgrade impossible because the installed rpm simply cannot read these new rpms. The solution is: Fedora has issued an update to F-10 "rpm" package which is aware of this new format. So, you'll have to run a "yum update" on F-10 first (older Fedora's will have to be moved to fedora-10 and then updated via "yum update"). Once, this new "rpm" package is installed, then the upgrade should go smoothly. (Note: If you don't update "rpm", yum will fail with "MD5 sum mis-match" type of errors)

The delta between Fedora-10 and Fedora-11 is huge as compared to the previous deltas. There has been some heavy development. Lets see if Leonidas has the same majesty as the King ...

Debugging a segmentation fault using gdb

I am not a big proponent of gdb. If you *really* know what you are doing, gdb shouldn't be required. But, every now and then, you come across code that has used function pointers exclusively and then, hand-debugging becomes painful. gdb to the rescue.

You'll need the following pre-requisites to use gdb to debug a segmentation fault:
1) make sure you have compiled the executable WITH debugging symbols. i.e. the "-g" flag. eg
gcc -g -o hello hello.c
Without debugging symbols, gdb won't be able to do much.

2) Linux should core-dump on segmentation fault. Set:
ulimit -c unlimited
(man ulimit for more info)


Now just run that the excutable that is segfaulting. As soon as it segfaults, you should get an output something like "Segmentation fault (core dumped)". ls in your working directory and you will find a new core file has been created (probably with the name core.{pid})

Now, we just have to tell gdb to analyze this core. Here's how
gdb {executable} {dump file}

eg. gdb hello core.1324

Check out the output spit out by gdb and make sure that all debugging symbols have been loaded.
Now, on the gdb prompt:

(gdb) bt
(bt = backtrace .. prints stack strace)
with this backtrace you'll now know *exactly* where the program segfaulted. The code file, line number and the call which was the culprit.

You can even analyze variable values on any frame. Just change to that frame:
(gdb) frame {num}
eg. (gdb) frame 2

and use:
(gdb) info locals
(gdb) info args
to query the values of local variables and passed arguments, respectively.

With all this info, you can pin down the exact reason for the segfault pretty easily. Saves a lot of time!

Packages: Naming scheme

Its been a while since I wrote a nice article and today I just felt that inner need to write one. Today's topic is an introduction to the naming scheme used to manage packages. But, before that it'll be useful to distinguish between some similar terms.

Package: This is the common name that we generally use. Eg. "Amarok" is a package name
Build: A build is a particular release of a package. eg "Amarok-1.4.12-1.fc10" is a build. Note that a build specification is architecture independent.
RPM: An RPM is the architecture specific binary of a build. Eg. "Amarok-1.4.12-1.fc10.i386.fc10.rpm" is an rpm.
SRPM: Source RPM is architecture independent and contains the sources of the build packaged as an rpm. (Now, why would that be useful, you may ask. Why not a tarball? That'd take up another post to clarify. Queuing the topic)

Naming scheme:
Generally, a build is named in the following manner.
Name-Version-Release (popularly known as the NVR of a package)
Name: might be a simple name such as "Amarok". It can contain the hyphen character.
Version: Version is usually in x.y.z format. "z" being the least significant and "x" being the most significant. Usually, if a respun rpm contains only bug-fixes, only the "z" part is incremented. If there are some major changes or feature additions, "y" is incremented. An architectural change warrants an "x" increment.
But, some packages (like tzdata) use a different versioning scheme. (Since, tzdata package deals with timezone stuff, they find it convenient to include the year in the version. Eg. 2007k, etc.) But, an overwhelming majority use the x.y.z scheme.

Release: It is generally only a decimal number. It can be viewed as the minor version number. If the change is very small, so that incrementing even "z" is unjustified, release number is incremented. It might contain small bugfixes or other minor changes.

When, someone distributes a version of the rpm that deviates from upstream, (he has applied his own patches to the source) he should change the release number to reflect the same. A string is to be appended to the release number.
eg. If someone patches amarok to add his own cool new feature. He has to change the release number from "1" (say), to "1.fa1" or something similar. Just append a string at the end. So, when you see a non-standard package, you can instantly make out from the name.

RPMs also contain the architecture name along with the NVR.

Now, suppose you have 2 packages "blah-1.2.3-1.fc10" and "blah-1.2.3-1.fc11". And, there's a bug-fix which only applies to the fc10 version, what do you do? Certainly, you cannot change the Version number or Release number of the fc10 rpm because it was a "fc10" specific fix and hence, not a property of the build. In such a case, the build is spun as "blah-1.2.3-1.fc10.1". But this is a fairly rare case.


Well, This was a fairly basic post. But, this one merely does the job of heralding a series of posts on messing with RPMs and SRPMs. So, stay tuned!