The problem has to do with OpenOffice.org throwing out the following error when trying to boot in Hardened Gentoo:

terminate called after throwing an instance of ‘std::bad_alloc’
what(): std::bad_alloc

Turns out this has to do with the way OpenOffice.org tries to work against the mprotect restrictions. You can lift those restrictions by using paxctl (emerge -av paxctl) in the following way:

# check for current PaX settings:
paxctl -v /usr/lib/openoffice/program/soffice.bin
# disable mprotect:
paxctl -m /usr/lib/openoffice/program/soffice.bin

Now OOo should finally launch. This enables you to write a polite letter to the OOo team asking them to allow us to run OOo with mprotect.

Turns out that just yesterday, the Spanish GFO presented the correct way to fix this. You can simply create the file /etc/portage/package.license and add a line that accepts the AdobeFlash-10.1 license for the Adobe Flash package in portage:
echo "www-plugins/adobe-flash AdobeFlash-10.1" >> /etc/portage/package.license

Just add the line with the command above and rerun emerge -uDN world to upgrade Adobe Flash.

Update Jun 21, 2010 @ 14:00: You will, however, need the nspluginwrapper package to use Adobe Flash in a 64-bit browser. Also note this bugreport in special and the other bugreports in general.

First problem was not that hard to figure out: caff is not called caff in most packagemanagers. So, as I use Gentoo, I typed
emerge -av signing-party
and was on my way.

Caff stores it’s configuration in a user specific file called ~/.caffrc which can just be kept default to be honest. All you need to do is enter your full name, your email address, your keyid (see the config itself for instructions) and optionally customize the message to be sent. The real trick comes when editing some customizations for gpg.

For example, I wanted to define a default signing level. As you may or may not know, PGP keysigning can be fine-tuned by defining your level of confidence in establishing the key owner’s identity. All in all, as there was some checking of ID’s and confirming those, but doing this outside and using only one ID of variable quality, I felt level 2 would be the most appropriate (I’ll write a personal key signing policy in the near future). After some searching around I discovered that it was indeed not the right place to set this in caffrc, as the gpg-sign-args option was not meant to be used like that. To set this default I would normally have to add this preference to ~/.gnupg/gpg.conf, however, caff uses it’s own gnupg homedir, so nano -w ~/.caff/gnupghome/gpg.conf and add the following:
default-cert-level 2
(and any other customizations you feel that are needed, such as “charset utf-8″, and did you switch to SHA256 already btw?)

You may, however, use gpg-sign-args to avoid having to manually save the changes after signing each key, if you like. Insert the following in ~/.caffrc:
$CONFIG{'gpg-sign-args'} = 'save';

After this, the signing of specific keys with caff should work just fine. But there’s still the issue of being able to actually send out those keys by email to the owner. For that purpose we can use the very basic sSMTP, which is most likely already present on your system. If not, and when using Gentoo Linux:
emerge -av ssmtp

sSMTP comes with two config-files, which both need to be edited to work with my provider’s TLS enabled mailserver (just like Google’s Gmail for that matter). I’ll provide you with both the files (stripped of comments) the way I have them functioning properly:

/etc/ssmtp/ssmtp.conf
root=postmaster
mailhub=mail.provider.tld:587
AuthUser=username
AuthPass=password
rewriteDomain=
hostname=email@domain.tld
FromLineOverride=YES
UseSTARTTLS=YES

/etc/ssmtp/revaliases
root:email@domain.tld:mail.provider.tld:587
defaultuser:email@domain.tld:mail.provider.tld:587

Finally, this enabled me to send out the signed keys using caff. The current version of caff does add an invalid Sender header consisting of username@hostname unfortunately, though this has reportedly been solved recently. I solved it myself by inserting the Sender line which was added in the patch mentioned above. Feel free to propose other enhancements in the comments.

Update, 16 February 2010: I now have a personal keysigning policy! For automatically adding the policy URL to signatures, I use the following option in gpg.conf:
set-policy-url http://url/to/policy

Fine, now, on your local machine (LOCAL), generate an IdentityFile to be used for mounting the remote filesystem. I suggest that, while root, you execute the following:
ssh-keygen -f /root/.ssh/YOURKEYFILE
Assure that permissions are set accordingly:
chmod -R 700 /root/.ssh
Now, get the /root/.ssh/YOURKEYFILE.pub file. Yes, the one ending in .pub, not your secret one. Now, on the machine REMOTE, I suggest you add a new user, to be used solely for mounting with sshfs. Give it a catchy name like REMOTEUSER:
useradd -m REMOTEUSER
password REMOTEUSER #do not leave this blank!
Now make sure that the contents of YOURKEYFILE.pub get appended or added to /home/REMOTEUSER/.ssh/authorized_keys (which is of course on REMOTE, not on LOCAL). I don’t know (or care) how, use scp, use another machine, use an USB stick, you’ll figure it out.

After all this, you should be able to log into REMOTEUSER from LOCAL by executing the following as root:
ssh -i /root/.ssh/YOURKEYFILE -p REMOTEPORTNUMBER REMOTEUSER@REMOTE
If this does not work, check logfiles or use debugmodes.

From here it’s not that much work to get to mounting disks or folders which are physically on REMOTE to LOCAL. First, make sure you have sshfs installed. In Gentoo you can simply emerge:
emerge -av sshfs-fuse
Do this.

Now, make sure you know your LOCALMOUNTPOINT (and ensure the empty folder exists by using mkdir) on LOCAL and know which REMOTEMOUNTPOINT you want to mount (located on REMOTE). Try mounting it by executing the following as root:
sshfs REMOTEUSER@REMOTE:REMOTEMOUNTPOINT LOCALMOUNTPOINT -pREMOTEPORTNUMBER -o uid=LOCALUSERID -o gid=DESIREDGROUPID -o idmap=user -o IdentityFile=/root/.ssh/YOURKEYFILE -o allow_other
Please pay close attention to which value is entered where, and, if in doubt, read man sshfs. The values for LOCALUSERID and DESIREDGROUPID determine with what ownership the REMOTEMOUNTPOINT is mounted on LOCAL. The numbers entered represent uid and gid numbers residing on LOCAL.

If this works as expected, it is a simple matter of reformatting the above command, so /etc/fstab is able to automatically mount your REMOTEMOUNTPOINT at (LOCAL)boot. Or so I thought. Turns out it was slightly more complicated, but after some trial and error and some more searching the web I came up with the following working line for fstab:
sshfs#REMOTEUSER@REMOTE:REMOTEMOUNTPOINT LOCALMOUNTPOINT fuse port=REMOTEPORTNUMBER,uid=LOCALUSERID,gid=DESIREDGROUPID,idmap=user,IdentityFile=/root/.ssh/YOURKEYFILE,allow_other 0 0
That should do the trick! You can test this by ensuring you have not mounted your REMOTEMOUNTPOINT on LOCAL at this moment (try fusermount -u LOCALMOUNTPOINT) and then simply entering:
mount LOCALMOUNTPOINT #Yes, the one you just entered in /etc/fstab
That’s it! Any comments or questions can be directed to the comments below and I will attempt to adjust the above as needed.

Yet after some more searching I discovered that ntpd quits if it discovers that the time offset is too large. As my server time was about 1 hour off, that kind of made sense. Another logfile revealed that this was indeed the issue:
tail /var/log/syslog

time correction of -3635 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.

So how do we do that? Easy:
date MMDDhhmmYYYY #(Month, Day, hour, minute and Year)

And presto, problem solved! Do note that some programs may not appreciate sudden jumps in system time which you do cause by manually setting system time.

After some first attempts at fixing SELinux settings, switching SELinux on and off, rerunning rlpkg -a -r, and obviously furiously checking /var/log, I was out of ideas and started searching the web for anyone with a similar problem.

There I found many suggestions, such as checking ~/.xsession-errors (how did I miss that?). Turns out this file was cut off rather abruptly, without (at least so it seemed to me) a clear reason and clearly different from any other .xsession-errors files I had available. Hence reinforcing my idea that some SELinux kernel panic was the reason for my troubles.

When searching through Gentoo Bugzilla, I stumbled upon bug #274887, concerning a kernel panic occurring when using sys-kernel/hardened-sources-2.6.28-r9 and SELinux. A simple workaround was to use selinux_compat_net=0 when booting the kernel. Turns out that this finally fixed it for me. Yay! Now to decide: wait for the devs to apply the kernel patch or manually upgrade to a newer (non-stable) kernel?

Also, an update to the Gentoo 10.0 live DVD has been released, so download the Gentoo 10.1 anniversary live DVD for x86 or amd64.

Ah, for me it’s been only about three years since I went from Ubuntu to Gentoo Linux, but it was a great moment: finally the control over my OS that I was craving for, which was my reason for leaving Windows in the first place. Now all I’m waiting for is an official Gentoo shop to buy a professionally pressed copy of the Gentoo 10.1 Live DVD…

In this case, the forumposts lead me to the rather easy solution: if, when using Gentoo, you encounter a problem with dependencies, simply run revdep-rebuild:
revdep-rebuild -p
In this case, nss turned out to be the culprit and after a remerge (rerun revdep-rebuild without the -p flag) Firefox 3.5 would load as expected.

If you happen to find this page, but are not a Gentoo, but a different Linux or even a Windows or Mac OSX user, try some of the suggestions suitable for your OS, found in the Mozilla Developers Center.

[edit]28 July: according to the visitor numbers, I’m not the only one to experience this error. If people want to let me know whether this did or did not solve the issue for them, leave a comment below.[/edit]

Figured I’d try enabling and disabling some of the USE flags for Pidgin, but without any luck, it still crashed. Then I went for compiling it with the debug USE flag enabled, as was suggested when running from the terminal. (yeah, yeah, should’ve gone for that sooner )

This time I found out the crash occurred immediately when the perl module was probed:

(22:11:20) plugins: probing /usr/lib/purple-2/perl.so
Hi, user. We need to talk.
I think something’s gone wrong here. It’s probably my fault.
No, really, it’s not you… it’s me… no no no, I think we get along well it’s just that…. well, I want to see other people. I… what?!? NO! I haven’t been cheating on you!! How many times do you want me to tell you?! And for the last time, it’s just a rash!
Aborted

Somehow it crashed right there, but I have as of yet not figured out why. My (temporary) solution is to merge Pidgin with the perl USE flag disabled, as it is enabled by default.

Enter nano
nano -w /etc/portage/package.use
and append or insert the following line:
net-im/pidgin gtk -perl
(if you use Gnome by default you’ll probably not need to add the gtk USE flag)

When remerging Pidgin after this, I can open the plugins dialog without any problems. Thing is: I can’t reproduce this problem on my trusty little netbook, which is rather odd. Probably has something to do with my perl install or config… but I don’t feel like diving in there (yet). It works, I’m happy, but if anyone has any suggestions, feel free to drop me a line.

On a related note, I prefer the smileys used on Gathering of Tweakers and found out they are included in the smileypack available through Portage.

If you’re using stable, you’ll find that it is masked, so add
x11-themes/pidgin-smileys ~x86
(change for whatever arch you’re using) to package.keywords:
nano -w /etc/portage/package.keywords
and you are free to emerge the pack:
emerge pidgin-smileys
You don’t have to restart Pidgin to enable them, just head on over to preferences and enjoy!

Update 25th of June 2009: You can also extract the larger DiGiTheme zipfile in ~/.purple/smileys for even more GoT (and some MSN) smileys

* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.

(‘installed’, ‘/’, ‘perl-core/IO-Compress-Zlib-2.015′, ‘nomerge’) pulled in by
perl-core/IO-Compress-Zlib required by world

(‘ebuild’, ‘/’, ‘perl-core/IO-Compress-2.020′, ‘merge’) pulled in by
~perl-core/IO-Compress-2.020 required by (‘installed’, ‘/’, ‘perl-core/IO-Zlib-1.09′, ‘nomerge’)
~perl-core/IO-Compress-2.020 required by (‘ebuild’, ‘/’, ‘virtual/perl-Compress-Zlib-2.020′, ‘merge’)
~perl-core/IO-Compress-2.020 required by (‘ebuild’, ‘/’, ‘virtual/perl-IO-Compress-Base-2.020′, ‘merge’)
(and 5 more)

(‘installed’, ‘/’, ‘perl-core/Compress-Zlib-2.015′, ‘nomerge’) pulled in by
perl-core/Compress-Zlib required by world

Fortunately, after seeing this and having seen poppler doing the exact same, I knew the solution. Clearly perl-core/Compress-Zlib and perl-core/IO-Compress-Zlib were somehow present in world, while they should be mere dependencies.

The fix was just like last week’s fix:
emerge -C perl-core/Compress-Zlib perl-core/IO-Compress-Zlib

Easy does it! For more details, see the previous post.