Bei mir geht AIM in Kopete nicht mehr. ICQ aber problemlos. Bin aber nicht motiviert, für das blöde AOL Klumpatt einen andern Client zu probieren.
bug oder so in kopete ... icq hatte das protokoll geändert ... gibt auch ein paar seiten, wenn man mit google sucht
am besten updaten ... zb mit gentoo klappst dann wieder
emerge --sync (neue Packagelists)
und dann gibt's 1000 Möglichkeiten
emerge -u world (alles aktualisieren)
emerge kopete (Kopete mergen)
emerge -u kopete (Kopete samt Abhängigkeiten mergen, falls Updates)
emerge -u kdenetwork (kdenetwork updaten - da ist Kopete drin, falls du die Metapackages verwendest... um das rauszufinden, am besten mal mit -pv mergen, dann siehst du, obs schon vorhanden ist, oder was blockiert)
............... (siehe http://www.gentoo.de/doc/de/handbook/handbook-x86.xml?part=2)
war wer schneller 
... vorher vielleicht die pakete unmasken ... glaub nicht, dass die bereits freigeschalten sind?! falls doch oder bereits getan ist das untere unnötig
d.h., in /etc/portage/package.unmask kopete unmasken:
>=kde-base/kopete-3.5_beta1
müsste auch reichen(?!):
>=kde-base/kopete-3.5in /etc/portage/package.keywords entweder nur die 3.5.5-Versionen freischalten:
~kde-base/kopete-3.5.5 ~x86
oder alle nachkommenden:
~kde-base/kopete ~x86in /etc/portage/package.use alle use-flags aktivieren, falls du sie nicht in make.conf bereits drin hast:
kde-base/kopete addbookmarks alias autoreplace connectionstatus contactnotes gadu groupwise highlight history irc latex netmeeting nowlistening slp sms statistics texteffect translator webpresence winpopup xscreensaver yahoo
das flag jingle weglassen, weil momentan anscheinend noch verbuggt
bei mir dürfte "*-r2" das aktuellste sein (/edit: besser gesagt, kde-base/kopete-3.5.5-r2)
1. würd ich arts aus den Useflags nehmen (in /etc/make.conf -arts bei USE=".." hinzufügen), sollte ja seit alsa nicht mehr nötig sein und hat bei mir nur Probleme verursacht.
2. schreibt er eh hin was nicht passt:
[blocks B ] >=kde-base/kdelibs-3.5.4-r2 (is blocking kde-base/kde-env-3-r4)
[blocks B ] =kde-base/kdenetwork-3.5* (is blocking kde-base/kopete-3.5.2)
Also die jeweils 2 Pakete vertragen sich nicht, das linke blockt jeweils das in den Klammern, d.h. der will das in den Klammern installieren und kann nicht. Meist is es dann eh so, dass das neue die Funktionalität des blocking packages übernimmt, weswegen ich die blockierenden teile einfach immer unmerge (`emerge -Cav kdelibs kdenetwork`). kdelibs klingen irgendwie wichtig, aber nachdem er die eh gleich wieder drauf schmeissen will würd ich mir da mal keine Gedanken machen. Was es mit dem kdenetwork auf sich hat.. k.a.
Und diese Versionsherumscheisserei ist auch ein Grund, warum ich KDE eigentlich nicht mehr besonders mag 
Also einfach unmergen ist hier unter Umständen nicht das, was man will.
Warum blockiert's? Ich hab's oben schon geschrieben, entweder man installiert Meta-Ebuilds wie kdenetwork oder die einzelnen Pakete wie kopete. Unmergt man nun kdenetwork, sind alle Programme aus dem Meta-Package weg und müssen einzeln installiert werden, will man sie wieder haben.
Warum blockieren auch die kdelibs? Wahrscheinlich ist kdenetwork geunmaskt, kopete nicht. Jetzt benötigt die ältere Kopete Version auch eine ältere kdelibs-Version. 2 verschiedene gleichzeitig geht nur über die Portage-Slots zwischen Major Releases von KDE, nicht aber hier. kde-env ist bei neuen kdelibs-Versionen nicht mehr notwendig, deswegen scheint das hier extra auf noch. Und ja, die kdelibs sind ziemlich wichtig, ohne die läuft gar nix von KDE. Die ältere Version könnte schon ein Problem sein, schließlich sind alle anderen KDE-Sachen mit den aktuelleren kdelibs gebaut worden. Überhaupt sind die Versionen dann ziemlich durcheinander, andere KDE-Pakete würden wieder mit den alten kdelibs gebaut werden, was aber nicht klappt.
Ich würde also in dem Fall einfach kdenetwork updaten.
Hmm... wieso steht denn da ein Downgrade von kdenetwork? Außerdem, 3.5.2 wirkt nicht sonderlich aktuell, kam Anfang des Jahres raus.
Hmm... wieso steht denn da ein Downgrade von kdenetwork? Außerdem, 3.5.2 wirkt nicht sonderlich aktuell, kam Anfang des Jahres raus.
sorry, aber das is ein scheiß! wieso muss das immer so kompliziert sein
mir hat jemand gesagt, ich soll das:
ACCEPT_KEYWORDS="~x86" emerge -av kdenetwork
machen, das hab ich gemacht, wenn ich das jeztt noch mal eingeb:
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] kde-base/kdebase-3.5.5-r1 [3.5.2-r1] USE="arts cups hal opengl pam ssl -debug -ieee1394 -java* -kdeenablefinal -kdehiddenvisibility -ldap -lm_sensors -logitech-mouse -openexr -samba -xcomposite -xinerama -xscreensaver -zeroconf" 0 kB
[ebuild U ] kde-base/kdenetwork-3.5.5-r1 [3.5.2] USE="arts ssl -debug -kdeenablefinal -kdehiddenvisibility -rdesktop -sametime -slp -wifi -xinerama" 9,022 kB
Total size of downloads: 9,022 kB
Would you like to merge these packages? [Yes/No]
>>> Emerging (1 of 2) kde-base/kdebase-3.5.5-r1 to /
>>> checking ebuild checksums
>>> checking auxfile checksums
>>> checking miscfile checksums
>>> checking kdebase-3.5.5.tar.bz2
>>> checking kdebase-3.5-patchset-03.tar.bz2
!!! ERROR: kde-base/kdebase-3.5.5-r1 failed.
Call stack:
ebuild.sh, line 1555: Called dyn_setup
ebuild.sh, line 668: Called pkg_setup
kdebase-3.5.5-r1.ebuild, line 86: Called built_with_use 'sys-apps/dbus' 'qt3'
eutils.eclass, line 1619: Called die
!!! sys-apps/dbus-0.60-r4 does not actually support the qt3 USE flag!
!!! If you need support, post the topmost build error, and the call stack if relevant.
kommt das, wenn ich nur emerge -pv kdenetwork mach, kommt das:
These are the packages that would be merged, in order:
Calculating dependencies... done!
[blocks B ] >=kde-base/kdelibs-3.5.4-r2 (is blocking kde-base/kde-env-3-r4)
[ebuild N ] kde-base/kde-env-3-r4 0 kB
[ebuild UD] kde-base/arts-3.5.2-r1 [3.5.5] USE="alsa mp3 vorbis -artswrappersuid -debug -esd -jack -kdeenablefinal -kdehiddenvisibility -nas -xinerama" 0 kB
[ebuild UD] kde-base/kdelibs-3.5.2-r6 [3.5.5-r5] USE="alsa arts cups spell ssl tiff -acl -debug -doc -jpeg2k -kdeenablefinal -kdehiddenvisibility -kerberos -legacyssl -openexr -pertty% -xinerama -zeroconf" 0 kB [2]
[ebuild R ] kde-base/kdenetwork-3.5.2 USE="arts ssl -debug -kdeenablefinal -kdehiddenvisibility -rdesktop -sametime -slp -wifi -xinerama" 0 kB
Total size of downloads: 0 kB
Portage overlays:
[1] /usr/local/portage
[2] /usr/local/portage/xgl-coffee
!!! Error: The above package list contains packages which cannot be installed
!!! at the same time on the same system.
kaetzchen baby #
und was soll ich jetzt davon halten?
Zitat von Babysorry, aber das is ein scheiß! wieso muss das immer so kompliziert sein
Hehe.. also ich würd dir wirklich raten, wenn du einfach nur ein gemütliches System willst wo du nicht viel rumspielen und auf hundertausend Sachen achten musst, damits ordentlich läuft, dann vergiss Gentoo und tu dir irgend ein easy-to-use-System drauf. Ubuntu z.B. ist ganz nett
Zitat von BabyACCEPT_KEYWORDS="~x86" emerge -av kdenetwork
Ahm.. sowas würd ich nicht machen, macht nur Probleme bei Updates u.ä. und verursacht Versionsprobleme.
Wennst was unmasken willst mach's mit /etc/package.keywords für soft- bzw. /etc/package.unmask für hard-masked Sachen, so wie eh der carbon hier im Thread weiter oben schon geschrieben hat.
Zum Rest trau ich mich jetzt konkret nichts sagen, schaut nach messy Versionen/USE-Flags aus. Mir hilft da forums.gentoo.org immer sehr. Praktisch alle Probleme die ich hab, hatte da vor mir schon ein anderer
ACCEPT_KEYWORDS ist nur selten eine gute Idee.
Damit hast du zwar erstmal die aktuellen Pakete installiert, jedoch sobald du irgendwas mit Portage machst, was irgendwie in die Nähe dieser Pakete oder deren Abhängigkeiten kommt, hast ein Problem. Das sieht dann so aus wie bei dir...
Besser wäre es, wenn du Pakete mit Keywords versehen möchtest wie mit ACCEPT_KEYWORDS, diese in /etc/portage/package.keywords einzutragen.
Sieht so aus:
x11-wm/beryl
kde-base/kdenetwork ~x86
Je nachdem, ob du's für alle Keywords (fast, aber egal...) oder nur für ein bestimmtes unmasken möchtest.
Damit ist dann auch das Problem behoben, dass ACCEPT_KEYWORDS auch Abhängigkeiten mit dem Keywords versieht, was auch Probleme macht (sieht bei dir ebenfalls danach aus). Willst du die Abhängigkeiten jedoch wirklich mit dem Keyword versehen, dann trag sie ebenfalls ein, für manche ist das notwendig, ist nervig, aber sonst sieht's halt kaputt aus...
Ich würde qt3 in die USE-Flags eintragen, falls nicht schon ist, kann mich zwar nicht mehr genau an deine Fehlermeldung erinnern, aber ich glaub', das brauchst auf jeden Fall. Ansonsten würde ich mal die Pakete in die portage.keywords eintragen, die du dort haben willst und dann mal ein emerge -up world oder so machen, um zu sehen, wo die Versionen nicht passen, dann möglichst auf den vorgeschlagenen Stand bringen...
Das ist, was ich gestern geschrieben habe... du willst ein Package installieren, das gemaskt ist und brauchst dazu Abhängigkeiten, die ebenfalls gemaskt sind. Einfach die Pakete, die er nicht installieren kann ebenfalls in die package.keywords eintragen. Ich würde überhaupt KDE entweder komplett mit Keyword oder komplett ohne verwenden.
fürs Auflösen der kde-Abhängigkeiten für die aktuellsten Pakete ist eine bestehende Liste am besten, ansonsten kanns wirklich zur Schwerstarbeit werden ... gibt eh auch im genannten forums.gentoo.org welche, neben KDE-Update-Anleitungen ... ansonsten wirklich mal ohne probieren
ich häng zur Unterstützung der anderen Beiträge eine solche dran, wär halt Versionen-begrenzt, was nicht so das Gelbe vom Ei ist
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!