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

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?

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.

During my initial emerge -uDN world I was confronted with the following list of blocks:

Conflict: 7 blocks (6 unsatisfied)

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

(‘ebuild’, ‘/’, ‘dev-libs/poppler-glib-0.10.7′, ‘merge’) pulled in by
~dev-libs/poppler-glib-0.10.7[cairo] required by (‘installed’, ‘/’, ‘media-gfx/gimp-2.6.4′, ‘nomerge’)
~dev-libs/poppler-glib-0.10.7[cairo] required by (‘ebuild’, ‘/’, ‘virtual/poppler-glib-0.10.7′, ‘merge’)

(‘ebuild’, ‘/’, ‘dev-libs/poppler-qt3-0.10.7′, ‘merge’) pulled in by
~dev-libs/poppler-qt3-0.10.7 required by (‘installed’, ‘/’, ‘kde-base/kpdf-3.5.10-r1′, ‘nomerge’)
~dev-libs/poppler-qt3-0.10.7 required by (‘ebuild’, ‘/’, ‘virtual/poppler-qt3-0.10.7′, ‘merge’)

(‘installed’, ‘/’, ‘app-text/poppler-bindings-0.10.5-r1′, ‘nomerge’) pulled in by
app-text/poppler-bindings required by world

(‘ebuild’, ‘/’, ‘app-text/poppler-utils-0.10.7′, ‘merge’) pulled in by
~app-text/poppler-utils-0.10.7[abiword] required by (‘ebuild’, ‘/’, ‘virtual/poppler-utils-0.10.7′, ‘merge’)
~app-text/poppler-utils-0.10.7[abiword] required by (‘installed’, ‘/’, ‘net-print/cups-1.3.10-r1′, ‘nomerge’)

(‘ebuild’, ‘/’, ‘dev-libs/poppler-0.10.7′, ‘merge’) pulled in by
~dev-libs/poppler-0.10.7 required by (‘ebuild’, ‘/’, ‘dev-libs/poppler-glib-0.10.7′, ‘merge’)
~dev-libs/poppler-0.10.7 required by (‘ebuild’, ‘/’, ‘virtual/poppler-0.10.7′, ‘merge’)
~dev-libs/poppler-0.10.7 required by (‘installed’, ‘/’, ‘app-office/openoffice-3.0.0′, ‘nomerge’)
(and 2 more)

For more information about Blocked Packages, please refer to [snip]

Now if I read through this list carefully I might have spotted the culprit before resorting to a websearch, but unfortunately I didn’t. Both poppler*-0.10.7 and poppler*-0.10.5-r1 were required and I didn’t realize why.

Turns out the solution was my sloppy Gentoo-past haunting me: poppler does not belong in world. In the past I may have emerged software that did not belong in world without -1, as I just didn’t see the issue with that. Well, here it was.

To remove poppler (and others) from world, use:
emerge -C app-text/poppler app-text/poppler-bindings
Followed by
emerge -uDN world
(assuming you have set –ask (and –verbose) as EMERGE_DEFAULT_OPTS)

For anyone who, after reading this, is still somewhat puzzled as to the how and why of world, try the Gentoo documentation on Portage or browse through man emerge.

In my own (probably not quite correct) words: whenever you install a major piece of software, use emerge without -1, to ensure it is recorded in the so called world file. Whenever you update your world file using emerge -u world, the packages in the world file will be updated. In case a package is a dependency, Portage will automatically upgrade it once something in the world file requests it. As poppler was recorded in the world file, while it should have been a dependency, a conflict arose when other package in world were requesting an update. So whenever you have the need to manually install a dependency, use emerge -1 [packagename].

TL;DR: no dependencies in world please.

But it failed.

nmap: unrecognized option '--script'
[snip: followed by regular nmap --help output]

Eh?

As my thinking was suspended, I went for Google to find me the culprit responsible for this error. No results. What? Ah, well, this is just why I wanted my own blog: to enhance Google with yet unknown knowledge (or knowledge previously only available in obscure languages). Now only to find the solution…

Turns out it was actually rather simple: compile Nmap with the lua USE flag. Yes, that’s all.

OPEN PACKAGE.USE
nano /etc/portage/package.use
AND INSERT
net-analyzer/nmap lua
OR ON A TERMINAL ENTER
echo "net-analyzer/nmap lua" >> /etc/portage/package.use

After this you’re good to go.

While I’m at it, let’s leave you with the recommended scan options at the moment of writing:

#Source: Nmap changelog
o Recommended command for a fast Conficker scan (combine into 1 line):
nmap -p139,445 --script p2p-conficker,smb-os-discovery,smb-check-vulns
--script-args checkconficker=1,safe=1 -T4 [target networks]
o Recommended command for a more comprehensive (but slower) scan:
nmap --script p2p-conficker,smb-os-discovery,smb-check-vulns -p-
--script-args checkall=1,safe=1 -T4 [target networks]