Kernel upgrade

For some time I had been trying to upgrade the kernel on my Gentoo box from 2.6.29 to 2.6.30. I was interested in 2.6.30 kernel because of three reasons.

#1 From what I remembered from the experiements with sreadahead, this kernel was supposed to support it well. However, recently when I dug into the topic, Jeremy told me that it is very much a dead project now. I still have baselayout2 and openRC to tinker with to obtain boot speed improvements.

#2 I had a secondary LAN port installed. So, I had to configure my kernel for that. I decided that since a new kernel is available, I shall install the driver and the kernel too.

#3 This kernel supports LZMA compression. I was interested in trying it out.

I compiled the kernel fine, editted grub.conf and rebooted into my experiemental kernel. During the boot, I could clearly see that sreadahead was a dead project. It took me straight to kdm screen. However, after kdm the system froze.

My first idea was to check the command line. So, I restarted and from kdm went to command line. Invoking the following, I found that the driver for the LAN interface was fine.

lspci -k

I was clueless as to what went wrong. I thought I might need to build xorg-server, input drivers and video drivers against my new kernel. So, I ran the following command.

emerge -v xorg-server xf86-video-intel xf86-input-evdev

After that once again, I tried to get back to GUI using. However the system froze again. I thought lets get some help. Checking on #gentoo, I was suggested to try what I had done as explained above. I kept looking at IRC for four days without any solution to my problem. Then, thinking my KDE might be having issues, I tried at #gentoo-kde where Aleister suggested I might have enabled KMS and using xorg-server 1.5 at the same time. My X server log file at

/var/log/Xorg.0.log.old

was reporting fatal server error. Checking my menuconfig, I found that he was right. Disabling that option, I was able to do away with system freezes. All I lost was the two penguins that appeared during boot. The problem was xorg-server 1.5 does not support kernel mode setting (KMS).

Stages in software development

During development of software, debugging becomes easy when we have working code after each commit. O'Rielly's "must read" articles for programmers also recommend planning each commit well. This actually is a better way than unit testing, though is much the same in some cases. The advantage here is the developers are not only sure of the working of the newly added unit but also of its integration with the rest of the code.

To exemplify, I share the following screenshots. The screenshots are of an rtf file renderer. The folowing is the screenshot after foreground color implementation. Here the font size is rendedred double the required size. Also note the unnecesary space in between the letters 'm' and 'p' of the word "example". There are other similar cases too.

In the next commit, the font size problem is fixed, yet the problem of unnecessary space remains unsolved, though it doesn't seem to make much difference.

Then the unnecessary space problem was solved.

In the subsequent commit, double underline support was added.

The above were the screenshots of successful additions to the software. However, in between these, there must be numerous trials that reveal error in implementation. The point is while attempting to get a particular task done and properly integrated reduces debugging load.

The process described above is typical in scripting languages like Python, Lisp, etc. Following these lines in languages like C isn't difficult either. Its just one task at a time. So you build the base first - an unpolished prototype of a prototype - add features to it and improve the base to integrate better with the added features, i.e. bottom up.

Gentoo incremental updates

Gentoo linux has been releasing weekly snapshots instead of usual long term releases. This is a nice way of providing cutting edge technology. To add to that, Gentoo does not provide updates regular way. Ebuilds are stabilized by developers and whenever we want to update our system, we have to follow the subsequent steps:

* emerge -v --sync

This updates ebuilds.

* emerge -pv --deep --newuse --update world

This gives a list of changes that shall be made. In case, there is change of USE flags, this command will detect the packages that need to be reinstalled.

This unique updating method keeps Gentoo users at cutting edge of technology. However, there are some drawbacks. A dependency resolution problem occurs when a particular package has been stabilized; but some of its dependencies are not. In this case, portage complains that the dependencies are masked. This is what happened to me last night.

emerge -pv --deep --newuse --update world

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy ">=x11-libs/qscintilla-2.4[python]" have been masked.
!!! One of the following masked packages is required to complete your request:
- x11-libs/qscintilla-2.4 (masked by: ~x86 keyword)

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
(dependency required by "dev-python/PyQt-3.18.1" [ebuild])
(dependency required by "media-sound/amarok-1.4.10_p20090130-r3" [installed])
(dependency required by "world" [argument])

I checked out with people at #gentoo channel on IRC. The discussion could not solve the issue. I decided to postpone the update and got back to work. After about 3 hours, I synced again. The dependency problem wasn't solved. I had not installed any masked packages and PyQt wasn't also present in package.keywords. I was just hoping the incremental releases had got into a situation I described earlier as a drawback of the Gentoo update system. So, I postponed the update till morning.

Today morning, when I synced I noticed a change in PyQt ebuild. When I ran a pretended update, I got the following list of updates.

emerge -pv --deep --newuse --update world

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] app-portage/portage-utils-0.1.29 78 kB
[ebuild U ] app-shells/bash-4.0_p28 [3.2_p39] USE="net%* nls -afs -bashlogger -examples -plugins -vanilla" 6,155 kB
[ebuild U ] dev-db/sqlite-3.6.17 [3.6.16] USE="readline%* threadsafe -debug -doc -soundex -tcl" 2,912 kB
[ebuild U ] sys-devel/libtool-2.2.6a [1.5.26] USE="-test% -vanilla" 717 kB
[ebuild U ] app-emacs/emacs-common-gentoo-1.2 [1.0] USE="X -emacs22icons%" 46 kB
[ebuild NS ] app-editors/emacs-23.1 [22.3-r2] USE="X alsa gpm toolkit-scroll-bars xpm -Xaw3d -dbus -gif -gtk -gzip-el -hesiod -jpeg -kerberos -m17n-lib -motif -png -sound -source -svg -tiff -xft" 33,577 kB
[ebuild U ] virtual/emacs-23 [22] 0 kB
[ebuild U ] app-admin/eselect-python-20090824 [20090606] 5 kB
[ebuild U ] dev-python/sip-4.8.2 [4.7.9] USE="-debug -doc%" 601 kB
[ebuild U ] dev-python/setuptools-0.6-r1 [0.6_rc9] 253 kB
[ebuild U ] sys-libs/pam-1.1.0 [1.0.4] USE="cracklib nls -audit -debug% (-selinux) -test -vim-syntax" 1,564 kB
[ebuild U ] sys-auth/pambase-20090620.1-r1 [20081028] USE="cracklib sha512 -consolekit -debug -gnome-keyring -mktemp -passwdqc (-selinux) -ssh" 3 kB
[ebuild U ] sys-auth/consolekit-0.3.0-r2 [0.2.10] USE="pam -debug -doc% -policykit%" 385 kB
[ebuild U ] app-admin/sudo-1.7.2_p1 [1.7.1-r1] USE="pam -ldap -offensive (-selinux) -skey" 753 kB
[ebuild U ] dev-python/PyQt4-4.5.4-r4 [4.4.4-r5] USE="X dbus kde -assistant -debug -doc -examples -opengl -phonon -sql -svg -webkit -xmlpatterns" 6,808 kB
[ebuild U ] dev-python/PyQt-3.18.1 [3.17.6] USE="-debug -doc -examples" 801 kB

Total: 16 packages (14 upgrades, 1 new, 1 in new slot), Size of downloads: 54,653 kB

My patience finally paid off. However, it would be wrong on your part to take the impression that this is general drawback of the Gentoo release system. That is because I am using KDE 3.5.10, which does not have upstream support any more. Unless you are in such an odd situation like me, Gentoo is a nice way of getting fine-tuned cutting edge software.

P.S.: A Gentoo forums thread clarifies that this is not a singular case.