# QT immer wieder eine Freude

## schmidicom

Vielleicht wurde das hier schon einmal diskutiert aber ich habe nichts entsprechendes gefunden deswegen:

Erst kürzlich scheint ja die QT Version 4.8 in portage auf stable gewechselt zu sein was beim update wie gewohnt zu einigen block's führte. An und für sich nicht weiter tragisch wenn man sich daran gewöhnt hat, also fix abmelden in die Konsole und selber Hand anlegen.

Doch warum das eigentlich, wieso kann portage diese nicht auf die selbe Weise aktualisieren wie z.B. GTK?

Ausserdem ist bei dieser QT Version jetzt auch noch was neues (eselect qtgraphicssystem) hinzugekommen das doch eigentlich eine Meldung unter "eselect news" verdient hätte. Denn ohne die Umstellung auf "nativ" mit "eselect qtgraphicssystem 1" hätte ich bei mir den KDE nicht mehr zum laufen gebracht.

Ist hier was vergessen gegangen oder ist an mir eine bereits allen bekannte News-Meldung vorbei gelaufen?

Was bei mir auch noch nötig wurde nach diesem Update von QT war das neu bauen aller Pakete deren Library in irgend einer Weise von QT abhängig waren und das waren eine Menge Pakete (fast das halbe System).   :Shocked: 

Ist das jetzt Normal?

Macht euch QT auch so viel Freude?   :Wink: 

----------

## franzf

 *schmidicom wrote:*   

> Was bei mir auch noch nötig wurde nach diesem Update von QT war das neu bauen aller Pakete deren Library in irgend einer Weise von QT abhängig waren und das waren eine Menge Pakete (fast das halbe System).  
> 
> Ist das jetzt Normal?

 

Nein, ist es nicht. Du redest von revdep-rebuild, oder? Hast du dir da auch genau angeschaut, warum die Pakete neu gebaut werden müssen? Ich habe das Qt-Update schon einige Zeit hinter mir, und es musste GAR NCIHTS neu gebaut werden.

----------

## schmidicom

 *franzf wrote:*   

> Du redest von revdep-rebuild, oder? Hast du dir da auch genau angeschaut, warum die Pakete neu gebaut werden müssen?

 

Zum Teil ja aber:

Nach dem update von QT habe ich wie immer revdep-rebuild laufen lassen doch der sagte das alles bestens sei, aber bereits direkt nach dem ersten Login war klar das eben nicht alles bestens ist (Etliche Programme die sich nicht öffnen liessen, Fenster ohne rahmen, Animationen die hängten, etc.). Also bin ich in die TTY1 zurück hab den X gekillt, die ganzen QT Pakete wieder deinstalliert und dann revdep-rebuild nochmal ausgeführt. Dann hat er neben QT natürlich auch alle Pakete die von QT abhängig waren neu gebaut und installiert.

Von da an ging dann auch alles wieder, deswegen auch der Satz:

 *schmidicom wrote:*   

> Was bei mir auch noch nötig wurde nach diesem Update von QT war das neu bauen aller Pakete deren Library in irgend einer Weise von QT abhängig waren und das waren eine Menge Pakete (fast das halbe System).   

 

----------

## franzf

 *schmidicom wrote:*   

> die ganzen QT Pakete wieder deinstalliert und dann revdep-rebuild nochmal ausgeführt. Dann hat er neben QT natürlich auch alle Pakete die von QT abhängig waren neu gebaut und installiert.

 

Oh Wunder  :Very Happy: 

Was macht revdep-rebuild? Es sucht nach nicht aufgelösten Verweisen in Binaries, findet die zugehörigen Pakete und baut neu. Klassiker: libpoppler.so.13 wird nicht gefunden, da das Ding jetzt libpoppler.so.19 heißt.

Wenn also ein Binary die libQtCore.so referenziert, du aber qt-core und damit die libQtCore entfernt hast, meint revdep-rebuild, dass da was nicht in Ordnung ist, und baut entsprechende Pakete neu (z.B. qwt) - dass qt-core gar nicht (mehr) installiert ist, interessiert revdep-rebuild gar nicht.

Da das Bauen selber wieder mit portage (emerge) geschieht, wird VOR dem Bauen der betroffenen (->revdep-rebuild) Pakete alles an qt-Abhängigkeit installiert.

Also insgesamt ein Schein-Problem mit einer Schein-Lösung - oder so  :Razz: 

----------

## schmidicom

Wenn du mir nicht glaubst versuch es doch selbst und deinstalliere mal dein QT und mach dann ein revdep-rebuild. Der installiert dir nicht nur QT sondern auch alle Pakete deren Library mit denen von QT verlinkt waren.

Ob das jetzt sinnvoll ist oder nicht musst du jene Fragen die revdep-rebuild geschrieben haben.

----------

## franzf

 *schmidicom wrote:*   

> Wenn du mir nicht glaubst versuch es doch selbst und deinstalliere mal dein QT und mach dann ein revdep-rebuild. Der installiert dir nicht nur QT sondern auch alle Pakete deren Library mit denen von QT verlinkt waren.
> 
> Ob das jetzt sinnvoll ist oder nicht musst du jene Fragen die revdep-rebuild geschrieben haben.

 

Ja, das weiß ich doch und glaub es dir. Ich wollte nur erklären, warum das so ist. revdep-rebuild hat halt die eine Aufgabe, kaputte binaries zu finden. Dass der User mutwillig was kaputt gemacht haben könnte interessiert den nicht.

Hättest du vor dem revdep-rebuild ein emerge -uDN world laufen lassen, hätte revdep-rebuild ja auch gar nichts fixen wollen  :Wink: 

----------

## Klaus Meier

So ganz verstehe ich deine Probleme nicht. PORTAGE_ELOG hat bei mir Meldung gemacht. Warum muss dass in als portage news kommen? Und bei mir musste ich nichts ändern, default war richtig. Des weiteren, qt löschen und dann revdep-rebuild laufen lassen? Ist doch klar, dass da alles neu gebaut wird. Alles, was eine Abhängigkeit zu qt hat hängt ja in der Luft. Woher soll revdep-rebuild wissen, dass qt ja während des Laufes wieder gebaut wird? Die Reihenfolge ist: emerge -uDN world, wenn das gut gegangen ist eventuell (aber wirklich hinschauen, was da passiert) emerge --depclean und dann auf alle Fälle revdep-rebuild.

Oder um es anders zu sagen: Warum kann ein Einbeiniger nicht laufen, wenn er sich ein Bein abhackt? Mach ein emerge -C gcc und wundere dich, dass nichts mehr geht.

Um es ganz einfach zu sagen: Wenn du ein Problem hast, poste es doch hier, bevor du es noch schlimmer machst. Es gibt hier absolut kompetente, nette Hilfe. Du kannst natürlich selber machen, was du willst, aber dann beschwere dich bitte nicht.

----------

## Josef.95

 *schmidicom wrote:*   

> Erst kürzlich scheint ja die QT Version 4.8 in portage auf stable gewechselt zu sein was beim update wie gewohnt zu einigen block's führte. An und für sich nicht weiter tragisch wenn man sich daran gewöhnt hat, also fix abmelden in die Konsole und selber Hand anlegen.
> 
> Doch warum das eigentlich, wieso kann portage diese nicht auf die selbe Weise aktualisieren wie z.B. GTK?

 

Nunja, Qt ist im Gegensatz zu GTK ja in einzelne Pakete (Qt Module) aufgesplittet so das man die Möglichkeit hat nur die Module zu installieren die auch wirklich benötigt werden.

Und hart-Blocks sollte es beim normalen "emerge -avuDN world" i.d.R nicht geben, wenn dann sind es normal nur angezeigte soft-Blocks (mit kleinem b) die portage selbst passend auflöst. Sprich normal braucht man nur noch mit Enter bestätigen, dann sollte das Qt Upgrade normal problemlos gebaut und installiert werden (hier tat es das).

Und das nun ab Qt 4.8 per default die Graphics Engine auf raster gesetzt wurde, welche mit dem nun neuen eselect Modul qtgraphicssystem je nach bedarf gesetzt werden kann, wurde auch schon zusätzlich vor Monaten auf Planet Gentoo vorgestellt - siehe hierzu Heads up: How to set your default graphics engine in Qt-4.8.0

Meiner Meinung nach haben die Gentoo Devs das ganze Upgrade auf Qt 4.8 gut vorbereitet um es problemlos durchführen zu können. Normal sollte dabei eigentlich nichts schief gehen.

----------

## py-ro

Es ist einfach das falsche Tool benutzt.

revdep-rebuild prüft auf Library-Ebene und installiert nur die Pakete mit kaputten vermerken neu, das Abhängigkeiten dann reingezogen werden liegt eben an emerge.

Ein emerge -u world hätte nur Qt gezogen, da hier die nur Abhängigkeit erkannt wurde.

Aber im Grunde wurde das weiter oben schon geschrieben.

Bye

Py

----------

## schmidicom

Erstens habe ich nie gesagt das es falsch ist das revdep-rebuild sich so verhält, das war nur ein Kommentar im Bezug auf das was "franzf" geschrieben hat. Ich persönlich bin froh das revdep-rebuild sich so verhält denn mir wäre jetzt keine andere Möglichkeit bekannt alles neu zu bauen was von einer bestimmten Library (in diesem Fall QT) abhängt.

Und zweitens sehe ich jetzt echt nicht was ich denn so unglaublich falsch gemacht haben soll...

Das Upgrade von QT wurde meinerseits sauber durchgeführt und anschliessen verweigerte der KDE den Dienst, erst danach fing die Bastelei an.

----------

## Apheus

Wenn Portage die Blocker nicht selbst auflöst, hast du möglicherweise Qt-Pakete oder sonstige Libraries im world-file:

```
grep x11-libs/qt /var/lib/portage/world
```

Die müssen da raus. Genauso mal nach "lib" suchen. Falls es da Treffer gibt - mal nachforschen ob das betreffende Paket wirklich in world stehen muss.

Ansonsten kann ich bestätigen was hier schon gesagt wurde: Nach dem Update von 4.7.4 auf 4.8.? musste nichts neu gebaut werden, die Blocker hat Portage selbst aufgelöst, und die Standardeinstellung von "eselect qtgraphicssystem" funktioniert (Ich glaube das ist "raster", und ich habe eine nVidia-Grafikkarte mit nvidia-Treiber).

----------

## py-ro

Hat ja keiner behauptet das du was falsch gemacht hast, allerdings weiß ich auch nicht wo die Voreinstellung für den Render-Modus bei dir herkam, ich hab die Tage selber einige System neu gemacht und dort war es immer korrekt einsgestellt.

Ich kann aber auch bestätigen das die anderen Modi nicht wirklich funktionieren.

Py

----------

## Klaus Meier

Dein Fehler war, qt zu löschen und sich dann zu beschweren, dass revdep-rebuild alles neu baut. Nicht mehr und nicht weniger...

Also, so schlimm ist es auch nicht.

Nun mal der Reihe nach. Es gibt Blocks, die mit "b" bezeichnet werden und welche mit "B". Die mit "b" kannst du ignorieren, die lösen sich von alleine auf. Die mit "B" gibt es eigentlich nur wenn du dein System ewig nicht aktualisierst oder Pakete manuell unmaskierst. Die lassen sich aber mit etwas /dev/brain meistens beheben.

Einfach die logs lesen, da steht alles drin. Und revdep-rebuild ist dein Freund. Nicht emerge -C.

----------

## Finswimmer

Da es passt:

Bei meinem Update eben habe ich auch richtig Blocks (B) bekommen. 

Dies lag daran, dass kwave in einer Version installiert war, die explizit qt:4.7 benötigte.

Daher habe ich eine neue Version freigeschaltet und die Blocks haben sich selbst aufgelöst.

----------

## schmidicom

Wenn diese Softblocks so unbedeutend sind warum werden diese dann angezeigt?

Im Moment ist es bei meinem Laptop immer noch so das ein umstellen von qtgraphicssystem auf raster dazu führt das der KDE nicht mehr startet, nur auf nativ funktioniert es. Bei meinem festen Computer zu Hause konnte ich diese Einstellung auf raster lassen, dort gab es keine Probleme.

Vielleicht hängt das ja mit der Grafikkarte zusammen den beim Laptop ist eine intel on cpu am Werk und beim PC eine Radeon.

 *Klaus Meier wrote:*   

> Dein Fehler war, qt zu löschen und sich dann zu beschweren, dass revdep-rebuild alles neu baut. Nicht mehr und nicht weniger...

 

So langsam verstehe ich die Behauptung aus einem anderem Beitrag das du einem Worte in den Mund legst.

Ich habe mich nie darüber beschwert das revdep-rebuild alles neu baut wenn QT deinstalliert wird. Das war eine Beschreibung dessen was ich machen musste um KDE wieder zum laufen zu bringen.

----------

## franzf

 *schmidicom wrote:*   

>  *Klaus Meier wrote:*   Dein Fehler war, qt zu löschen und sich dann zu beschweren, dass revdep-rebuild alles neu baut. Nicht mehr und nicht weniger... 
> 
> So langsam verstehe ich die Behauptung aus einem anderem Beitrag das du einem Worte in den Mund legst.

 

Ich hatte es aber auch genau so verstanden. Es hat mMn. einfach die klare Aussage ich habe Qt entfernt, um revdep-rebuild alle Pakete neubauen zu lassen, die mit Qt zu tun haben. gefehlt. Dann wäre sofort klar gewewsen, dass dir bewusst war, wie die Zusammenhänge sind.

Ansonsten scheint aber die Ursache für dein Problem nicht in "broken libraries" zu liegen, sondern im falschen qtgraphicssystem - oder habe ich das jetzt auch wieder falsche verstanden?

Und Abhängige Pakete findest du auch mit

```
equery d qt-core
```

usw.

----------

## Klaus Meier

 *schmidicom wrote:*   

> So langsam verstehe ich die Behauptung aus einem anderem Beitrag das du einem Worte in den Mund legst.

 

Ok, wenn du ein Problem damit hast, dass man seine Beiträge auf das bezieht, was du schreibst, dann habe ich dich verstanden. Dann kann ich nur sagen, wie zu dem anderen, den du hier zitierst, ich werde deine Beiträge lesen aber nie wieder etwas dazu schreiben.

----------

## schmidicom

 *franzf wrote:*   

> Ich hatte es aber auch genau so verstanden. Es hat mMn. einfach die klare Aussage ich habe Qt entfernt, um revdep-rebuild alle Pakete neubauen zu lassen, die mit Qt zu tun haben. gefehlt. Dann wäre sofort klar gewewsen, dass dir bewusst war, wie die Zusammenhänge sind.

 

Ich dachte es wäre klar genug geschrieben aber wenn dem nicht so war, entschuldige ich mich dafür.

 *franzf wrote:*   

> Ansonsten scheint aber die Ursache für dein Problem nicht in "broken libraries" zu liegen, sondern im falschen qtgraphicssystem - oder habe ich das jetzt auch wieder falsche verstanden?

 

Naja aus meiner Sicht war es zu diesem Zeitpunkt beides ("broken libraries" und qtgraphicssystem), und das versuchte ich auch zu beschreiben. Jetzt weiss ich nicht mehr was ich glauben soll.

Denn nach dem ersten erfolglosen Versuch KDE zu starten schaute ich mir zuerst die .xsession-erros an und da fand ich massenhaft ("undefined symbol" und "cannot load") die alle hinter einer Library von KDE standen. Da hatte ich dann die Idee revdep-rebuild wie oben beschrieben zu nutzen um diese Fehlermeldungen loszuwerden (wegen dem vorher gemachten QT Update lag die Vermutung nahe das dies die Fehlerquelle ist), was auch funktionierte. Doch der KDE wollte immer noch nicht so richtig also änderte ich noch qtgraphicssystem in nativ um und seit dem läuft alles wieder.

----------

## franzf

 *schmidicom wrote:*   

> .xsession-erros an und da fand ich massenhaft ("undefined symbol" und "cannot load") die alle hinter einer Library von KDE standen.

 

Hast du die .xsession-errors mit den Meldungen vllt. noch?

Sowas bekommt man bei Qt gerne, wenn irgendwo inkompatible qt-libs rumliegen, und AFAIR auch, wenn das Qt-Update noch nicht abgeschlossen ist, man z.B. die qt-core-4.8.1 bereits installiert hat, aber noch mit qt-gui-4.7.4 fährt. Letzteres sollte bei dir nicht zutreffen, da du ja das ganze Update abgewartet hast und danach erst die Probleme angefangen haben.

undefined symbols kann revdep-rebuild nun leider nicht abfangen - libraries sind ja vorhanden, aber sie enthalten bestimmte Symbole nicht, die referenziert werden.

----------

## schmidicom

 *franzf wrote:*   

> Hast du die .xsession-errors mit den Meldungen vllt. noch?

 

Nein, die habe ich leider nicht mehr.

----------

## Erdie

FYI

Bei mir lief der Update auf QT4.8 auf 2 Maschinen ohne die Notwendigkeit irgendetwas neu zu bauen problemlos durch.

----------

## forrestfunk81

Wenn revdep-rebuild nach dem QT Update nicht alle Abhängkeiten richtig erkannt hat, bist du wahrscheinlich über diesen Bug gestolpert. Redhat und Ubuntu hatten wohl ähnliche Probleme.

----------

