From new user to kernel compilation to upstream fix
It is quite exciting when helping new users solve issues while migrating to the Linux operating system, and Ubuntu Linux in this case.
A couple of weeks ago, a new member at the Ubuntu-gr forum posted a question about a sound problem in an Ubuntu Linux installation.
Alsa Mixer
Here is the timeline
- An initial post was made with the relevant hardware information.
- More information was gathered that led to the PCI ID and subsystem ID of the sound card, which further led to the source of a patch for a quirk.
- The advice to recompile the full kernel (with the patch) was given. This process required over 10GB, which caused the distribution to crash. The user was fine to reinstall.
- A subsequent route was taken to simply compile Alsa (not the full kernel) and add the patch.
- This route was successful and the sound was now working.
- We want to post this patch upstream so that newer versions of the kernel contain the fix. In addition, all distributions will benefit as well.
- A bug report was submitted to the Alsa bugtracking #0004561. We now wait.
- Days are passing with no progress. A question at #alsa (Freenode) shows that the Alsa bugtracking is probably not used, so there is need to contact the developers through the mailing list.
- An e-mail is sent to the Alsa mailing list with the patch. The Alsa developer takes the patch and applies to his tree. We missed by several days the release of Linux 2.6.30; the patch should appear in 2.6.31.
The whole process took ten days. It is amazing how rewarding it is to follow the open-source processes and contribute the personal time to help make open-source better.
The patch was evidently elemental, however it required new testing to make sure it works, and that it applies to the current state of Alsa. There are many areas that you can contribute some of your time to make open-source better.
I would like to thank Theodora for going through the process, locating and verifying the patch, so that now it is pending inclusion in Linux 2.6.31.
How to easily modify a program in Ubuntu (updated)?
Some time ago we talked about how to modify easily a program in Ubuntu. We gave as an example the modification of gucharmap; we got the deb source package, made the change, compiled, created new .deb files and installed them.
We go the same (well, similar) route here, by modifying the gtk+ library (!!!). The purpose of the modification is to allow us to type, by default, all sort of interesting Unicode characters, including ⓣⓗⓘⓢ , ᾅᾷ, ṩ, and many more.
The result of this exercise is to create replacement .deb packages for the gtk+ library that we are going to install in place of the system libraries. Because these new libraries will not be original Ubuntu packages, the update manager will be pestering us to rollback to the official gtk+ packages. This is actually good in case you want to switch back; you will have the enhanced functionality for as long as you postpone that update.
There is a chance we might screw up our system, so please make backups, or have a few drinks first and come back. I take no responsibility if something bad happens on your system. If you are having any second thoughts, do not follow the next steps; use the safer alternative procedure. You may try however this guide just for the kicks; up to the dpkg command below, no changes are being made to your system.
We use Ubuntu 7.10 here. This should work in other versions, though your mileage may vary.
The compilation procedure takes time (about 30 minutes) and space. Make sure you use a partition with >2GB of free space. We are not going to use up 2GB (a bit less than 1GB), but it’s nice not to fill up partitions.
We are going to use the generic instructions on how to recompile a debian package by ducea.
First of all, install the development packages,
sudo apt-get install devscripts build-essential
Next, we use the apt-get source command to get the source code of the GTK+ 2 library,
cd /home/ubuntu/bigpartition_over2GB/apt-get source libgtk2.0-0
We then pull in any dependencies that GTK+ may require. They are normally about a dozen packages, but we do not have to worry for the details.
apt-get build-deplibgtk2.0-0
At this stage we need to touch up the source code of GTK+ before we go into the compilation phase. Visit the bug report #321896 – Synch gdkkeysyms.h/gtkimcontextsimple.c with X.org 6.9/7.0 and download the patch (look under the Attachment section). You should get a file named gtk-compose-update.patch. If you have a look at the patch, you will notice that it expects to find the source of gtk+ in a directory called gtk+. Making a link solves the problem,
ln -s libgtk2.0-0 gtk+
We then attempt to apply the patch (perform a dry run), just in case.
patch -p0 --dry-run < /tmp/gtk-compose-update.patch
If this does not show an error message, you can the command again without the –dry-run.
patch -p0 < /tmp/gtk-compose-update.patch
Finally, we are ready to build our fresh GTK+ library.
cd libgtk2.0-0debuild -us -uc
This will take time to complete, so go and do some healthy cooking.
At the end of the compilation, if all went OK, you should have about a dozen .deb files created. These are one directory higher (do a “cd ..“). To install, use dpkg,
dpkg -i *.deb
If you have any other deb files in this directory, it’s good to move them away before running the command. If all went ok, the .deb files should install without a hitch.
The final step is to restart your system. To test the new support, see the last section at this post. Use Firefox and OpenOffice.org to type those Unicode characters.
If you managed to wade through all these steps, I would appreciate it if you could post a comment.
Good luck!
