I’m a sucker for bleeding edge technology. After posting before about upgrading to the 8.42.3 ati drivers, I realized I was using Xorg-X11 7.2, not 7.3, which is the latest. The latest 7.3 ebuild contains a block on the ati drivers. The block is no longer necessary though because the 8.42.3 drivers are compatible and have xorg-server 1.4 support built in.
Here is what I did to upgrade. Continue reading “Upgrading to Xorg-X11 7.3 with ati-drivers 8.42.3 on Gentoo”
Update: As of the last couple days (11/18/07), an ebuild has been added to portage for these drivers. It’s no longer necessary to create your own.
So the Long Anticipated ATI drivers that support AIGLX are released. I’ve been wishing for this long before anyone ever mentioned it was a possibility. I’ve got my Gentoo machine all set up with the new drivers and working with Compiz-Fusion. Here is the process I used to convert from Xgl and the 8.40.4 driver to the 8.42.3 driver with AIGLX.
Continue reading “AIGLX, Compiz-Fusion, Gentoo, and my ATI Radeon 9600 Card with 8.42.3”
If you run Gentoo Linux for your desktop, and you happen to favor the Gnome desktop environment, you may have noticed the incredible number of packages that need to be installed in order to install the gnome ebuild. The ability to pick and choose just those components you need for a system is one of the reasons I personally haven’t switched away from Gentoo to another Linux distribution. This ebuild however, seems to me to go somewhat against the original intent of the OS.
Continue reading “The perennially late Gentoo gnome-light ebuilds”
A few of the web applications I am hosting/developing are written with TurboGears which uses Cherrypy as its applications server. I have a couple things that need fixed for hosting CherryPy web applications on my Gentoo systems. First, there are no init scripts for CherryPy. Second, I’m running mulitple web applications per machine. I run them as different users with virtual python environments to keep web applications stepping on each others toes.
You can customize the logging for a TurboGears application to have not logging to standard out, but you still have to deal with the python CherryPy process not running as a daemon. I chose rather to run the application in a screen session.
First, a quick script to start my web application in its virtual python environment in my web applications directory.
cd `dirname $0`
And next, a real simply startup script that starts and stops the application in a screen session.
su -l $APPUSER -c "screen -S $SESS_NAME -d -m /$APP_DIR/$SCRIPT_NAME"
su -l $APPUSER -c "screen -S $SESS_NAME -X kill"
The variables can go in /etc/conf.d/<app_name> where the <app_name> is the same name as the init.d script. They will automatically be sourced and passed to the init script. For more information on Gentoo init scripts, check here.
I’m in the process of re-installing a pretty old machine with the latest Gentoo. I’ve got a shared NFS directory with portage and all my machines are using a packages directory. After one machine builds something, another machine can simply install the built package.
Here is a portion of the make.conf on each machine.
Well, this particular machine was installed with Glibc 2.3.x. I typed the following to do the upgrade:
emerge -auDvk system
About 1/3 of the way through the upgrade, tar suddenly stopped working:
tar: /lib/libc.so.6: version `GLIBC_2.4' not found (required by tar)
I realized that tar had been upgraded but the glibc was not yet upgraded. To fix the problem, I created a new version of tar on a different system:
USE="static" emerge -av tar # on another machine
scp :/bin/tar /bin/ # from the broken machine.
Off I go, things are working.
As part of a recent project, I had installed a lot of packages on a separate machine to test my configuration. As is common, with Gentoo, you want to run the following before you actually emerge anything:
emerge -p <package_name>
In this particular case, I noticed the dependency list was pretty long (50 packages to be exact). Instead of going ahead with the emerge, I first recorded the package list to a file for later reference:
emerge -p <package_name> --nospinner > dep.list
Now that I’m done with the project, I can clean up the packages I no longer need like this:
emerge -aC `cat dep.list | grep 'ebuild N' | cut -d ' ' -f 8`
Notice the grep. That is because a couple of the packages were simply upgraded and I don’t know that they aren’t needed. After a quick scan of the resulting list to see what is going to be uninstalled, I let emerge do the rest of the work.
Walla, no more 50 extra packages on that machine.