Gentoo emerge conflicts: SQLite and dev-perl/DBD-SQLite

February 13th, 2010 by sjan

I was having issues with my regular update schedule on my Gentoo server where I kept getting the following message:
('ebuild', '/', 'dev-db/sqlite-3.6.22-r2', 'merge') conflicts with
=dev-db/sqlite-3.6.22[extensions] required by ('installed', '/', 'dev-perl/DBD-SQLite-1.29-r2', 'nomerge')

Since I use SQLite fairly regularly and I like to keep it up to date I figured I would focus on getting that updated, then worry about the Perl SQLite. (Had I known that spamassassin relies on the Perl SQLite I may have been a little more hesitant, but it all worked out ok anyway.)

Here is how I managed to update both SQLite and the Perl SQLite. I first unmerged dev-perl/DBD-SQLite with:
emerge --unmerge dev-perl/DBD-SQLite

I then updated SQLite with:
emerge -u sqlite

Which changed the USE settings to “-extensions” which meant that when I tried to emerge DBD-SQLite it failed due to the missing USE requirements. So I took a stab at it and did:
USE="extensions" emerge sqlite
Which built cleanly without any problems, and after which a quick
emerge dev-perl/DBD-SQLite worked great.

So, in a quick and easy cut and paste format the work-around is:
emerge --unmerge DBD-SQLite
emerge -u sqlite
USE="extensions" emerge sqlite
emerge DBD-SQLite

Why the work-around is required I don’t know at the moment as I don’t have the time to dig through the ebuild files and figure out where the issue is, although I am sure if I had waited a bit updated ebuild files will come down the pipeline to correct the issue. (Patience is a virtue, but I have never been all that virtuous.)

Keeping Gentoo Fresh

May 31st, 2009 by sjan

I had a converstion with a friend about Linux distros earlier today, and I was asked why I choose to run Gentoo on my web server. He told me that Gentoo was too hard to maintain on a server, and that when it came time to upgrade something (like Apache or PHP) due to security patches that it took too long, and too often failed. I was confused by this so I asked for clarification. What he described was the pain of updating anything on a “stale” Gentoo machine.

Unlike so many of the other popular distros, Gentoo does not, by default, use pre-compiled packages. So unlike doing rpm -i or apt-get install doing emerge on Gentoo requires that the package you are installing, and any missing dependencies, are pulled in as source code and compiled. When you think about adding packages like, say, Lynx, the process takes only a few minutes on a moderately decent machine. (Mine is a PII 966 and Lynx took about 4 minutes start to finish). When you talk about upgrading something like Apache, however, the length of time it takes depends not only on the speed of the machine, but how many of its dependencies are out of date. In fact, if you fail to update regularly you can run into an issue where not only are most of your files out of date, but your system profile is out of date and you need to do some serious wrenching to get the whole thing working again. In the times that this has happened to me (twice) I was able to get the system up-to-date once, and just gave up and reinstalled a newer version the second time. (These were both rarely used VMs, and not production boxes.) However, updating the profile on a “fresh” Gentoo is (in my experience) a painless procedure of rm /etc/make.profile && ln -sf /usr/portage/profiles/profile_name /etc/make.profile && emerge -uND world (uND : update newuse deep: update, take into account new use settings from the profile and make.conf, and include deep dependencies).

So how do I avoid the “stale” Gentoo syndrome? I take a three-step approach.

  1. A daily cron job runs emerge -puvD world (puvD : pretend update verbose deep : just tells you what would be emerged, in an update, verbosely, and include deep dependencies) and emails me the output. This enables me to see each morning which packages have updates available.
  2. Every day that I have the time for it I log into the machine and run emerge -uD world and follow it up with etc-update (if needed) and revdep-rebuild if any libraries were included in the updates. (I save building new kernels for Sundays, and that doesn’t happen all that often, but I do like to always run the latest.)
  3. I check the messages from emerge to see if there are any special configuration changes that need to happen post-install that cannot be handled by etc-update. For instance, changing configurations in /etc/conf.d/packagename, new profiles or anything of that sort.

Ok, so I like to keep my system on the latest and keep a shiny new everything on it. How does that compare with something like, say, Debian? In Debian (and Debian-based distros) you can update packages to a certain point, after which the package for that version of Debian is no longer supported or updated. So you need to upgrade your version, and your kernel, which you do with apt-get upgrade dist. Seems easy enough. And how does Gentoo handle version upgrades? It doesn’t need to. If you keep your system up-to-date in the way I described your system will match whatever the latest Gentoo release has. In fact, I built my web server using Gentoo 2006.0 and have been keeping it up-to-date since then. (Gentoo seems to have stopped doing the biannual releases, btw – they are now releasing updated minimal install CDs nearly weekly for each architecture.)

Gentoo: Spamassassin crashed! What?

May 23rd, 2009 by sjan

Life has been rather hectic lately, and a few things have fallen by the wayside in the interim, including simple maintenance tasks like, oh, mowing the lawn, and cleaning out the folder of spam for bayseian analysis, and other fun items. So when my inbox started to be flooded with what seemed like ten times the normal amount of spam I get (very little of which leaves in the Inbox) I decided to take a quick look at the server and see what was going on.

I ran a quick /etc/init.d/spamd status and got the response *status: crashed – Uh oh. A quick check of running processes showed that spamd (the SpamAssassin daemon) was indeed not running. I did a quick restart and thought nothing of it. Spam traffic slowed right back down. For about 10 hours. Suddenly I was getting hammered again. Checked the server and once again *status: crashed – “Ok”, I thought. I restarted it yet again and then immediately checked the status. Again it showed as crashed. Checking the running processes with ps -a | grep spamd showed something different, however. It showed the SpamAssassin daemon happily chugging along.

A bit of searching brought me to the relevant bug report for Gentoo. It seems that there is something in the way SpamAssassin starts the daemon that causes the pidfile to not be written, which leaves OpenRC with the notion that it has crashed. The fix is there in the bug report, though. By changing the spamd init file ( /etc/init.d/spamd ) with the addition of a forced pidfile SpamAssassin starts and OpenRC is happy as well. All by adding the one line you see below (in bold):

        start-stop-daemon --start --quiet \
                --nicelevel ${SPAMD_NICELEVEL:-0} \
                --pidfile ${PIDFILE} \
                --exec /usr/sbin/spamd -- -d -r ${PIDFILE} "" \

Now if I could just find a one-line fix for an overgrown lawn. And dandelions …


The reason for the actual crashing was due to the overgrown spam folder for bayseian analysis. It seems that running the sa-learn utility against a 6 GB directory causes all sorts of Bad Things TM to hapen, as it parses every file (again) to determine whether it can “learn” from it. I cleaned out the directory and have had no problems since then.

Minor SVN hiccup

March 24th, 2009 by sjan

Anyone who tried to access SPDO via the subversion repo since Saturday may have run into a slight problem: namely a session that looked something like this:

ratatosk:svn sjan$ svn co spdo
svn: Could not open the requested SVN filesystem

I only became aware of it this morning, and I knew (almost) right away where the problem might lie. I was still able to access the repos via svn (in the internal network) and via file (from the server) but could not access them from http or https. I checked the svn version number and got this:

xxxx spdo # svn --version
svn, version 1.5.6 (r36142)
   compiled Mar 21 2009, 09:44:24

Copyright (C) 2000-2008 CollabNet.
Subversion is open source software, see
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

Ok, so this version built on Saturday when I did my latest updates. So, ra_svn works, ra_local works but ra_neon does not. I recalled that neon upgraded from 0.28.3 to 0.28.4 on the same day with the warning:

  * Neon has a policy of breaking API across minor versions, this means
 * that any package that links against neon may be broken after
 * updating. They will remain broken until they are ported to the
 * new API. You can downgrade neon to the previous version by doing:
 *   emerge --oneshot '<net-misc/neon-0.28'
 * You may also have to downgrade any package that has already been
 * ported to the new API.

That shouldn’t be needed (downgrading earlier than 0.28) since everything was working fine with 0.28.3 so, a quick

emerge --oneshot =net-misc/neon-0.28.3

and all is right with the world again.

Gentoo emerge error: Can’t locate Module/

December 9th, 2008 by sjan

When trying to do my regular emerge today I ran into minor snag. When emerge tried to build dev-perl/IO-Socket-INET6-2.56 emerge failed with the following error:

Can't locate Module/ in @INC (@INC contains: /etc/perl /usr/lib/perl5/vendor_perl/5.8.8/i686-linux /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl/5.8.8/i686-linux /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/5.8.8/i686-linux /usr/lib/perl5/5.8.8 /usr/local/lib/site_perl .) at Build.PL line 3.
BEGIN failed--compilation aborted at Build.PL line 3.

I did some searching and didn’t come across anything directly related to IO-Socket-INET6, but I did see references to other Perl libraries failing to build with the same error, and remark in one of the threads that the only work-around was to emerge the Perl Build module. So, I did an emerge Module-Build and followed it up with my usual emerge -auvD world and IO-Socket-INET6 built just fine.

It seems that there may be a few Perl libraries in Portage that are relying on the Build module but aren’t adding it as a requirement in their ebuild. If you have lots of Perl libraries installed that you manage via Portage you may want to save yourself some hassle and emerge Module-Build now.

Parallels 4: first impressions

November 16th, 2008 by sjan

I upgraded to Parallels 4 the other day, and hadn’t really had time prior to today to do anything more than open my old VMs and upgrade them to the new version. So today I decided to put it through some paces. I have a massive Gentoo Server VM built in VMWare (one that I built for work) and decided to see if I couldn’t use the Parallels Transporter to convert it for use on my MBP. I first tried to import the whole Virtual Machine and it failed most unceremoniously and quickly. Whether this is due to the disks being broken into 2GB chunks or due to the OS being Gentoo I’m not sure. So, on with plan 2. Use the Transporter to import the disks and then plug those into a new image. While it took a long (long) time, Parallels did successfully import the 2 disks from the VMWare image. I then created a new Virtual Machine and pointed the VM’s first hard disk at the first image, and added a second hard disk pointed at the second image I imported. Although when I imported the first disk image I set it to be a “Bootable Disk” Parallels complained and said there was no OS on the disk and it would not be bootable. I continued anyway, and good thing I did.

After setting up the VM I started it up and sure enough, it booted fine. I did have to change the setting in /etc/fstab as the second hard disk showed up in Parallels as /dev/hdc rather than /dev/hdb.

A little tinkering with network settings (changing from eth0 to eth2) and all was running swimmingly. Since the servers on the VM rely on shared folders being available in /mnt/hgfs/ (the VMWare Workstation & VMWare Player host shared folder mount point) and Parallels will not share folders except with a Windows VM (due to the need to install Windows-specific tools) I added some configuration to /etc/fstab to use samba to mount shares from the host. (Of course, it helps to remember to turn on Windows file sharing in the OS X host too!)

EDIT: Parallels Tools for Linux Guests does, indeed, share out OS X host folders! Thanks to Vasily Averin, developer of the shared folders driver for Linux guests for pointing that out. It puts the folders in /mnt/psf which means a couple symlinks and I was on my way. Thanks!

In addition to all this tinkering to bring in a VMWare image, I ran some updates on the other Gentoo Linux image I upgraded from Parallels 3, and tried out the new “Modality” view while portage was runnning a bunch of updates. If you haven’t seen it yet, it makes a tiny semi-transparent window of the VM which stays on top of all your other apps. You can pull it down somewhere out of your way and keep an eye on how your updates are coming along. Actually pretty handy for things like attended installs and such.

Coherence in Windows seems to run even smoother than previously and I noticed that my machine wasn’t heating up nearly so bad as it used to. When you are working on a laptop this is a very good thing, indeed.

There was a lot of talk in the upgrade information about an iPhone app to controll your VMs but it doesn’t seem to be out yet. I will keep watching the app store for it though.

Doing it the hard way, rather than the really hard way

October 31st, 2008 by sjan

When I shut down the server, prior to moving, I installed an extra hard drive I had laying around before packing it up to be shipped. With the move, and all the work and busy running about since then, I managed to forget that there was a 40GB drive, just waiting to be used.

The other day, I noticed in my daily email from the emerge –sync that cron runs, that it was unable to complete because there was not enough space on the disk. I logged on and df -h showed me that, yes, the drive was full. I did some cleanup and maintenance on the drive and managed to clear out about 1GB of space. This is important, because I needed to increase the size of my boot partition. When I first built this server (using Gentoo 2006.0) I had been having terrific results with a tiny little 32MB boot partition. Now I was having problems, because the boot partition didn’t have enough room to build the initrd for 2.6.27-gentoo-r1. I’m not sure why, but for some reason every kernel I have tried to compile after 2.6.25-gentoo-r1 (including r2, r3, r4, and r5 of the same kernel branch) would create an initrd that was in the 25MB range. Well, that plus a kernel and the configs and you have a no-go on a 32MB boot partition.

Anyway, after cleaning up the drive I was going to use parted to shrink the root partition and grow the boot partition. But parted requires that ext2 and ext3 partitions always start from the same block. Not a problem, the plan was to shrink the root partition, move the swap partition there and then grow the boot partition. Then the really hard part would have come – finding another drive (since this one was too small) and taking the entire server down for a rebuild. Ugh.

So I fired up parted and did a print all to see the block numbers for my partitions, and there it was, 40GB of unused space on another drive. (You probably heard the facepalm from wherever you are and wondered what that noise was.)

So, using good old cfdisk I created 3 partitions on the new drive, a 19GB ext3 partition, a 20GB ext3 partition and a 1GB swap partition. I copied the contents of /usr to the first, and the contents of /var to the second and used a little command chaining to put those where they belonged. (If you are curious, it went something like mv /usr /usr.old && mkdir /usr && mount /dev/hdd1 /usr followed by the same sort of chain for /var and then restarting a few services that point to files in var or usr).

I then did a swapon /dev/hdd3 swapoff /dev/hda2 and then edited fstab to match the new layout. Now for the fun part. Since I didn’t see a way in parted to delete a partition I shrunk the old swap partition down to 1MB, and then resized the boot partition to fill the new space. I did run into an issue where parted gave the error “Error: Filesystem has an incompatible feature enabled.” I found the fix for that to be using tune2fs to turn off resize_inode. That means no online resizing, but since this is not on an LVM that is not an issue. So, run tune2fs -O^resize_inode /dev/hda1 and then run parted and whoosh! A larger boot partition that will fit the massively fat initrd I am trying to stuff in there, and things are better. And with /usr and /var split off onto the new disk the root file system disk now has 11GB of space available.

And, in the spirit of doing things the hard way, I am posting this from my iPhone while laying about waiting for the stomach cramps to subside enough to sleep. (I hate this flu.)

Gentoo Apache 2.2 update and 403 errors

September 22nd, 2007 by sjan

After upgrading my entire system, moving from Apache 2.0.x to 2.2.6 I ran into an interesting problem (actually, a couple.) Some of the configurations have moved, and things that used to be in the Gentoo dist httpd.conf have been broken out into config files in the /etc/apache2/modules.d/ directory. So, copying my old vhosts file in was not a good idea. And doing a merge of the old and new httpd.conf files was also a mistake. Once I figured out that I had the Listen 80 directive in one file and Listen in another I understood why it failed to start. So, I fixed all the configs to match the new setup, and tried again. It started up just fine, and seemed okay, until I tried to connect. I kept getting 403 errors.

I went through the standard checks, checking the file permissions, .htaccess settings, and so on, to no avail. A quick Google search pointed me to the fix from Victor Trac. He found the offending bit in the new broken out config in /etc/apache2/modules.d/00_default_settings.conf where it contains:

<Directory />
        Options FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all

The fix is either to change that to Allow from all and define Deny where needed in each virtual host or to override it in every virtual host. Since I tend to set up my hosts with the idea that the server allows everything and it is up to the host to deny where needed I chose the first option, reloaded Apache and everything is sweet again.


I found I was having an error with the RewriteRules after switching from Apache 2.0.x to 2.2.x – I found the fix on the Gentoo forums, which required adding an extra RewriteCond line in the .htaccess file.

The old .htaccess: and the new:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
# END WordPress

and the new:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond $1 !\.php$
RewriteRule . /blog/index.php [L]
# END WordPress

Technorati Tags: , ,

Getting caught up

September 20th, 2007 by sjan

While things have been hectic preparing for the big move, some things have fallen by wayside. Like updating the server (ok, I can’t just blame that on moving, it hasn’t been done in a while) and updating the MySpace crossposter from Roderick Russell to version 2.0. That part, at least, was a piece of cake, and the options panel makes setup much easier.

It turns out the server was still running on the Gentoo 2006.0 profile and in order to bring things up to date I needed to get it to the 2007.0 profile. For anyone who hasn’t tried this, here is the easy way: run emerge –sync and then change the symlink /etc/make.profile to point to the newer profile (in this case /usr/portage/profiles/default-linux/x86/2007.0 – after that run emerge -u portage and then revdep-rebuild (in order to use revdep-rebuild you need to have the gentoolkit installed, which can be done via emerge gentoolkit. (It takes about 5 minutes to download and build.)

After running revdep-rebuild it was time to run the dreaded emerge -auv world. Running verbose shows clearly what is getting replaced, updated, added, etc and you get the nice red blocking messages.

In my case, pecl-zip was blocking php-5.2.4, and no amount of forcing was going to help, so for the duration of the upgrade I unmerged pecl-zip. I also had some blocking in that the current version of Postfix was not compatible with the new version, so the choice is to unmerge Postfix and then emerge (too long of a down-time) or by doing a FORCE_UPGRADE=1 emerge –buildpkgonly postfix followed by /etc/init.d/postfix stop and then emerge –usepkgonly postfix followed by a quick etc-update to merge the config file with the new configs and then restart the server with /etc/init.d/postfix start. Total downtime for the mail server: 2 minutes.

I am currently updating the last of the software (mostly admin and gnu tools) and then will build a new kernel. Of course, since there is a newer version of GCC included in the updates, everything that wasn’t updated will get rebuilt with another call to revdep-rebuild before I configure and compile the new kernel.

It’s not like any of this is difficult, especially when most of the ebuilds are so good about giving you help in their error messages (if there are errors) and often tell you in the message how to fix it step-by-step. Now, if I could just find the build that reminds me every week or so to run emerge –sync and check for updates. Hmmm – I might even put that in a weekly or daily cron job:

#update notifier
usr/bin/emerge --sync > /dev/null 2>&1 || true --nospinner && /usr/bin/emerge -puv world

Then it is just a matter of seeing what shows up as needing to be updated, and I can compare that with messages from the Gentoo Linux Security Advisories to determine which can wait and which are needed right now.

Technorati Tags:

Kororaa – Gentoo with (Xgl) Eye Candy

November 2nd, 2006 by sjan

While the debates carry on over what can be done to make Linux more feasible in the desktop market (in other words desirable enough that average users say “I want that!”) the one argument that seems to rise to the top is eye candy. Does it affect how an OS works? No. Does it change the way programs behave? Maybe superficially. Does it change the way users interact with the OS and the programs? You bet!

I had a chance to play with , a Gentoo-based live CD with AIGL/Xgl and a great install-to-disk tool. And while Xgl is not quite ready for prime-time (I encountered a couple crashes where xdm would completely exit and restart) it is getting close. And the eye candy features (adjustable transparency on windows, the rotating cube desktop, the “liquid-ish” movement of the windows) add a certain amount of “ooh factor.” But the biggest thing I found myself using were three very handy tools: [Ctrl+Shift+Alt+ left or right arrow] to rotate the desktop cube with the active window following, the hot-corner to display all the open windows as tiles, and the [Ctrl+Alt+PgDown] to “flatten” the cube, allowing you to see all the sides at once and use the arrow keys to select one of the desktops to switch to. While many will consider this to still be nothing more than eye-candy, I found it so utile that I am (a little too) eagerly awaiting the next Xgl implementation.

So who, besides me, thinks that these are as useful as they are eye candy-ish? Well, Apple, for one. They already have the hot-corner to display all the open windows, the ability to show all the open windows of one application, and (with Parallels at least – and rumor has it in the next OSX version) the cube concept of the multiple desktops.