blog.arithm

After doing an emerge world on an older box I get:

* Messages for package sys-libs/com_err-1.40.4:

* PLEASE PLEASE take note of this
* Please make *sure* to run revdep-rebuild now
* Certain things on your system may have linked against a
* different version of com_err -- those things need to be
* recompiled.  Sorry for the inconvenience

In other words, “This update is going to break your system. We kind of screwed up. Something changed. Here’s how to fix it.”

So now I don’t have to google around frantically trying to figure out why randomserviced is suddenly failing. And the Gentoo guys even apologize.

Honesty, transparency, and humility in software. Go figure.

Something else I should have known about long ago.   To turn on logging in portage, simply add the following to /etc/make.conf:

PORTAGE_ELOG_CLASSES="warn error log"
PORTAGE_ELOG_SYSTEM="save"

The will add log files for each package to /var/log/portage/elog/:

# ls -lah
total 108K
drwxrws--- 2 portage portage 4.0K 2008-06-06 01:13 .
drwxr-xr-x 3 root    root    4.0K 2007-10-04 12:29 ..
-rw-r--r-- 1 root    portage  200 2008-06-06 00:58 dev-db:postgresql-8.0.15:20080605-155810.log
-rw-rw-r-- 1 root    portage  72K 2008-06-06 00:44 summary.log
-rw-r--r-- 1 root    portage   67 2008-06-06 01:06 sys-apps:coreutils-6.10-r2:20080605-160624.log
-rw-r--r-- 1 root    portage  108 2008-06-06 01:08 sys-apps:shadow-4.0.18.2:20080605-160842.log


Useful to have around when you miss a barrage of announcements after a large emerge.

Looks like mktemp is now provided by coreutils.  No wonder.  This block has been bugging me (read: I’ve been ignoring it) for months.

To fix just unmerge mktemp and update coreutils.

Update: Same for the setarch / util-linux block should you come across it.  Unmerge setarch.

Here’s something I’d never had to do before. Be careful as this kind of tip will only popup for you once on the first emerge.

# emerge dev-php5/ZendOptimizer
>>> cfg-update-1.8.2-r1: Creating checksum index...
Calculating dependencies... done!
>>> Verifying ebuild Manifests... 

>>> Emerging (1 of 1) dev-php5/ZendOptimizer-3.3.0a to / 

!!! dev-php5/ZendOptimizer-3.3.0a has fetch restriction turned on.
!!! This probably means that this ebuild's files must be downloaded
!!! manually.  See the comments in the ebuild for more information. 

 *
 * Please download ZendOptimizer-3.3.0a-linux-glibc23-x86_64 from:
 * http://www.zend.com/products/zend_optimizer
 * and put it into /usr/portage/distfiles/.
 * Please note that you need a valid Zend Account
 * (free) to download the Zend Optimizer!

Manually pushing the archive into distfiles and running emerge worked fine. For a moment I was concerned that I might actually have to build something from source. Whew!

I really should learn to be more patient and read the docs. Today I stumbled across Gentoo compiler caching. From the About ccache section:

ccache is a fast compiler cache. When you compile a program, it will cache intermediate results so that, whenever you recompile the same program, the compilation time is greatly reduced. In common compilations this can result in 5 to 10 times faster compilation times.

Sheesh. How much time have I wasted sitting around drooling on myself waiting for portage to build package XYZ?

In addition to learning to read the docs I should also probably learn to stop drooling on myself.

This is quite convenient and is accurate (unlike the  g-cpan list command..):

perl -e 'use <module name>; print "ok\n"'

Can you tell that I’m fighting with CPAN modules and Gentoo?

mod_perl doesn’t play so nice with Gentoo. Perl and, specifically, g-cpan still seem to have problems.

I’ve been scratching my head (read: driving my head into my desk) over the following error:

Can't locate lib.pm in @INC (@INC contains: blah blah blah) at /etc/apache2/modules.d/apache2-mod_perl-startup.pl line 1.\nBEGIN failed--compilation aborted at /etc/apache2/modules.d/apache2-mod_perl-startup.pl line 1.\nCompilation failed in require at (eval 2) line 1.\n


Thanks to an obscure post at the bottom of a thread from a couple of years back I was able to fix it with

# perl-cleaner reallyall
# emerge libperl


perl-cleaner appears to be like revdep-rebuild, but Larry Wall style.

Now I can run Apache::ASP.

Thank you crazy Larry Wall people.

For some odd reason webapp-config didn’t want to upgrade my applications (namely this blog); it kept complaining that I hadn’t installed Apache and didn’t seem to know what Apache2 was.

* Fatal error: Your configuration file sets the server type "Apache"
* Fatal error: but the corresponding package does not seem to be installed!
* Fatal error: Please "emerge >=net-www/apache-1.3" or correct your settings.
* Fatal error(s) - aborting

I finally discovered that manually remerging webapp-config fixes the problem. Not sure why as the list of servers remains the same..

# webapp-config --list-servers
apache
aolserver
lighttpd
cherokee


Which leads me to the question, who in Sam Hill is running aolserver on Gentoo?!

I’ve been running a 空メール server for a number of years. As one might expect with a rule-based automated email reply system.. once in awhile the thing goes absolutely berserk. Usually I have to flop around the Internet trying to recover the commands I use (and promptly forget) to tame acid-tripping Postfix.

And generally this just boils down to postqueue -p to see what’s flying through and/or stuck in the queue and then postsuper -d ALL to clean it out.

Today, while tidying up, I came across pfqueue, a “console-based tool for handling MTA queues”. Looks great. Promptly tried it out and, surprise, surprise, while it emerges effortlessly on Gentoo, make install fails on my flavor of RedHat.

Need to figure this out. This tool could save me a ton of time.

Oh Lordy how I want to do this.