You thought I'm done with Gentoo bashing ? You thought wrong. Unfortunately they delayed a new Ubuntu release till June, so expect a few more posts about Gentoo before I can finally get away from it.
So first, automerging configuration changes broke at least 2 packages - apache and dictd. Both are kinda funny - Gentoo version of Apache is the only version ever made in which one cannot reload the configuration without stopping Apache first. Well, the Gentoo guys got a bright idea that instead of using regular configuration files, it's better to have configuration in /etc/conf.d/apache2, and pass that to the Apache server when it starts. Of course those files, unlike the regular Apache configuration, won't get reloaded on /etc/init.d/apache2 reload. Oh yeah, and they decided to break the configuration files on automerging and not even save a backup of the files before the automerge. That's one of the candidates for the biggest Gentoo annoyance, and the competition here is very tought.
And it broke dictd. Well, it got an idea that it should switch from Unicode to C. A short information for the dictd package maintainers - dictd does not work at all unless it's run in UTF-8 locale. The damn error message in /var/log/messages even tell me to switch to UTF-8 locale because dictd doesn't work in locale C. And does the unicode USE flag mean anything ? Not much apparently.
Let's forget the configuration mess for a moment. I wanted to check out high level languages for JVM. To my surprise, jRuby, Jython and Groovy were all available in portage. Wow, I thought, I doubt even Debian has them all, now Gentoo finally has a chance to shine. And guess what ? Not a single of them was installable. I even emerge sync'ed, but it didn't help any.
jRuby:
BUILD FAILED
java.lang.UnsupportedClassVersionError: org/apache/bsf/BSFManager (Unsupported major.minor version 49.0)
Jython:
>>> Compiling source in /var/tmp/portage/jython-2.1-r6/work/jython-2.1 ...
org/python/util/ReadlineConsole.java:23: cannot access org.gnu.readline.ReadlineLibrary
bad class file: /usr/share/libreadline-java/lib/libreadline-java.jar(org/gnu/readline/ReadlineLibrary.class)
class file has wrong version 49.0, should be 48.0
Please remove or make sure it appears in the correct subdirectory of the classpath.
Readline.load(ReadlineLibrary.byName(backingLib));
and a similar one for Groovy.
Just one last thing. Among the broken packages are pam-login and shadow. Should I uninstall them both and break the system in hope that the new versions compile correctly (and I don't have to login in the meantime) ?
# emerge -av pam-login shadow
These are the packages that would be merged, in order:
Calculating dependencies... done!
[blocks B ] sys-apps/pam-login (is blocking sys-apps/shadow-4.0.15-r1)
[blocks B ] >=sys-apps/shadow-4.0.14-r2 (is blocking sys-apps/pam-login-4.0.14)
[ebuild U ] sys-apps/shadow-4.0.15-r1 [4.0.7-r4] USE="nls pam -nousuid -skey" 1,264 kB
[ebuild U ] sys-apps/pam-login-4.0.14 [3.17] USE="nls -livecd -skey%" 1,217 kB
3 comments:
To fix the PAM-Login/Shadow error:
http://forums.kororaa.org/viewtopic.php?p=7016#7016
has a description:
Essentially, you run:
# emerge -C pam-login
# emerge -1 shadow
Basically that will unmerge the pam-login, and then upgrade the shadow package which now includes the "pam_login" module inside it.
After doing these two emerges, make sure that you can still login to your machine.
Good luck.
BIG MISTAKE. If you do this, shadow can accumulate a host of dependencies which would have to be emerged as well. If you successfully unmerge pam-login but fail or get cut off before shadow is installed, you will own a BRICK!
Do this instead:
FEATURES=-collision-protect emerge --nodeps shadow && emerge --unmerge pam-login
I know because that's how I got to your blog - looking for a way to recover 3 machines that did this simultaneously :(
heh, guess i found this page too late... Was experiencing same problem with dictd. Solution was easy, in /etc/conf.d/dictd add "--locale YOUR_LOCALE" to EARGS, like this:
EARGS="-s --locale ru_RU.UTF-8 "
Post a Comment