Spezielle USE-Flags für ein Paket und Demaskierung von Paketen unter Gentoo

Spezielle USE-Flags für ein Paket

Möchte man für ein Paket bestimmte USE-Flags setzen, ohne dass es in der make.conf global gesetzt wird, kann man die Datei /etc/portage/package.use verwenden.
Beispielsweise möchte ich für das Paket mysql die berkdb deaktivieren. Daher habe ich entsprechend:

dev-db/mysql -berkdb

in der obenstehenden Datei eingetragen.
Möchte man jedoch USB-Support für apcupsd (Ein Programm zur Steuerung von USV’s) haben, so muss man folgendes eintragen:

sys-power/apcupsd usb

Jedes Paket beansprucht dabei eine Zeile.

Spezielle Pakete demaskieren

Oft kommt es vor, dass man bestimmte Pakete installieren möchte, es aber von Portage mit dem Hinweis „All ebuilds that could satisfy „XXXX“ have been masked.„. Dies ist beispielsweise beim Paket „dev-php5/ZendOptimizer“ der Fall. Dieses Paket wurde für die Plattform x86 leider noch nicht stabilized, was man aber selbst in der Datei /etc/portage/package.keywords lösen kann. Das sollte man sich natürlich gut überlegen, manche Pakete werden jedoch „nie“ stabilisiert, weshalb man diesen Schritt schon mal gehen kann. Eine andere Möglichkeit ist beispielsweise bei Paketen, wo noch keine Version freigegeben wurde, eine Freigabe zu erzielen.

Dazu fügt man:

dev-php5/ZendOptimizer ~x86

hinzu, und schon wird die Maskierung für die Plattform x86 entfernt. Will man es für alle Plattformen freigeben, so genügt ein:

dev-php5/ZendOptimizer

Jedes Paket beansprucht dabei eine Zeile.

Gentoo: Can’t run java-config –help

Auf meinem Gentoo-Server ist mal wieder ein Fehler aufgetreten, der wie folgt aussieht:

~# java-config –help

Traceback (most recent call last):
File "/usr/bin/java-config-2", line 8, in
from java_config_2 import __version__
ImportError: No module named java_config_2

Lösung: java-config neu emergen.

ProFTPd: unknown configuration directive ‚AuthUserFile‘

Soeben habe ich einen ProFTPd-Server unter Gentoo mit der Direktive AuthUserFile konfigurieren wollen.
Dieser quittierte meinen Versuch mit der folgenden Meldung:

* Checking proftpd configuration ...
Checking syntax of configuration file
- Fatal: unknown configuration directive 'AuthUserFile' on line 44 of '/etc/proftpd/proftpd.conf'
* Configuration error: please fix your configuration file (/etc/proftpd/proftpd.conf).                      [ !! ]

Eine kurze Suche im Web brachte mich auf die Idee die USE-Flags zu überprüfen, was die Lösung brachte: Zu den USE-Flags muss authfile hinzugefügt werden.

All ebuilds that could satisfy „dev-java/sun-jdk“ have been masked: dlj-1.1 license(s)

Vor einigen Tagen ist mir beim Update der Java-Version meines Servers der folgende Fehler untergekommen:

!!! The following installed packages are masked:
- dev-java/sun-jdk-1.6.0.17 (masked by: dlj-1.1 license(s))
A copy of the 'dlj-1.1' license is located at '/usr/portage/licenses/dlj-1.1'.

- dev-java/sun-jdk-1.5.0.22 (masked by: dlj-1.1 license(s))
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

!!! All ebuilds that could satisfy "dev-java/sun-jdk" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-java/sun-jdk-1.6.0.18-r1 (masked by: dlj-1.1 license(s), ~x86 keyword)
A copy of the 'dlj-1.1' license is located at '/usr/portage/licenses/dlj-1.1'.

- dev-java/sun-jdk-1.6.0.18 (masked by: dlj-1.1 license(s), ~x86 keyword)
- dev-java/sun-jdk-1.6.0.17 (masked by: dlj-1.1 license(s))
- dev-java/sun-jdk-1.5.0.22 (masked by: dlj-1.1 license(s))

Die Lösung war das akzeptieren der Lizenz, wie bereits schon in der Meldung gesagt. Jedoch gibt es da verschiedene Möglichkeiten:

  1. Systemweites akzeptieren aller Lizenzen:
    Füge in der Datei /etc/make.conf die folgende Zeile hinzu:
    ACCEPT-LICENSE="*"
  2. Systemweites akzeptieren einer oder mehrer spezifischer Lizenzen:
    Füge in der Datei /etc/make.conf die folgende Zeile hinzu:
    ACCEPT_LICENSE="dlj-1.1
  3. Akzeptieren einer Lizenz für ein Paket:
    Füge in der Datei /etc/portage/package.license die folgende Zeile hinzu:
    dev-java/sun-jdk dlj-1.1

Ich habe mich für letzteres entschieden:

echo "dev-java/sun-jdk dlj-1.1" >> /etc/portage/package.license

Und schon war das Problem gelöst 🙂

Gentoo Linux: sys-fs/device-mapper is blocking sys-fs/udev-146

Heute kam die Meldung:

sys-fs/device-mapper is blocking sys-fs/udev-146

auf einem Server beim emerge hoch. Lösung war einfach:

emerge --unmerge sys-fs/device-mapper
emerge -av sys-fs/lvm2

sys-fs/device-mapper ist nun in lvm2 integriert worden / übergegangen, weshalb es nicht mehr benötigt wird.

Qemu 0.9.1 unter Gentoo installieren

Für ein neues Projekt habe ich heut auf Gentoo das Virtualisierungstool Qemu in der Version 0.9.1 benötigt. Blöderweise wird bei der Installation folgender Fehler geworfen:

* qemu requires gcc-3 in order to build and work
* correctly
* please compile it switching to gcc-3.
* We are aware that qemu can guess a gcc-3 but this
* feature could be harmful.

Qemu 0.9.1 unter Gentoo installieren weiterlesen

Fehler unter Gentoo: configure: error: C compiler cannot create executables

Gestern wollte mein Server nach einem World-Update unter Gentoo auf einmal keine Programme mehr kompilieren. Jedes Paket brach beim Kompilieren ab und meinte immer nur, man möge doch bitte mal die Logs prüfen. Dort fand ich dann den Fehler:

configure: error: C compiler cannot create executables

Was darauf hinwies, dass mit gcc was nicht in Ordnung war. Ein wenig suchen führte mich zu einem Thread im Gentoo-Forum, wo beschrieben war, man das Problem loswerden konnte. Anscheinend war bei der Installation von GCC4.3.2 was schief gegangen und nicht alles auf den neuen Kompilier umgelenkt worden. Darauf wies auch die Ausgabe von gcc-config -c hin:

~# gcc-config -c
* gcc-config: Active gcc profile is invalid!
[1] i686-pc-linux-gnu-4.3.2

Also flugs den gcc korrekt umgestellt:

~# gcc-config i686-pc-linux-gnu-4.3.2
* Switching native-compiler to i686-pc-linux-gnu-4.3.2 ...

* Your gcc has a bug with GCC_SPECS.
* Please re-emerge gcc.
* http://bugs.gentoo.org/68395

>>> Regenerating /etc/ld.so.cache... [ ok ]

* If you intend to use the gcc from the new profile in an already
* running shell, please remember to do:

* # source /etc/profile

Wie man erkennen kann, muss man dann aufgrund von Bug #68395 gcc nochmal neu emergen. Danach gings mehr oder minder wieder. Ein:

revdep-rebuild

Förderte noch die letzten Problemchen hervor und schon liefs wieder einwandfrei.