Nutzt schon jemand KDE5?

Message

franzf · Post by **franzf** » Wed Mar 18, 2015 8:11 am

@Yamakuzure: Kannst du mal den Patch probieren: (gegen qtgui:5)

--- src/plugins/platforms/xcb/qglxintegration.cpp.org   2015-03-18 07:38:33.012880213 +0100
+++ src/plugins/platforms/xcb/qglxintegration.cpp       2015-03-18 07:40:30.435872289 +0100
@@ -618,7 +618,7 @@
 // a fundamental flaw with multithreaded access to xcb, but mesa doesn't. The blacklist should be
 // reevaluated once that patch is released in some version of xcb.
 static const char *qglx_threadedgl_blacklist_vendor[] = {
-    "Mesa Project and SGI",                // QTCREATORBUG-10875 (crash in creator)
+//    "Mesa Project and SGI",                // QTCREATORBUG-10875 (crash in creator)
                                            // QTBUG-34492 (flickering in fullscreen)
                                            // QTBUG-38221
     0

Yamakuzure · Post by **Yamakuzure** » Fri Mar 20, 2015 7:31 am

franzf wrote:@Yamakuzure: Kannst du mal den Patch probieren: (gegen qtgui:5)

Code: Select all

--- src/plugins/platforms/xcb/qglxintegration.cpp.org   2015-03-18 07:38:33.012880213 +0100
+++ src/plugins/platforms/xcb/qglxintegration.cpp       2015-03-18 07:40:30.435872289 +0100
@@ -618,7 +618,7 @@
 // a fundamental flaw with multithreaded access to xcb, but mesa doesn't. The blacklist should be
 // reevaluated once that patch is released in some version of xcb.
 static const char *qglx_threadedgl_blacklist_vendor[] = {
-    "Mesa Project and SGI",                // QTCREATORBUG-10875 (crash in creator)
+//    "Mesa Project and SGI",                // QTCREATORBUG-10875 (crash in creator)
                                            // QTBUG-34492 (flickering in fullscreen)
                                            // QTBUG-38221
     0

Ah, ich habe es gelöst. Schuld war wohl die Live-Version. Ich habe ein "Downgrade" auf die Version 0.11.0 gemacht, und jetzt flutscht sddm.

Wahrscheinlich gibt es im Live build jede Menge debugging Zeugs (o.Ä.) das in der Release Version (natürlich) rausgenommen ist.

Die Live-Version hatte ich ursprünglich mal gewählt, als es nur die Version 0.7.0 (oder 0.8.0?) im Portage Baum gab, und mit der hatte ich an anderer Stelle Schwierigkeiten. Genau erinnere ich das nicht mehr.

franzf · Post by **franzf** » Fri Mar 20, 2015 12:27 pm

Probieren kannst du den Patch trotzdem. Ich hab ihn hier jetzt einige Tage am Laufen, ohne dass neue Probleme aufgetaucht wären. Dafür behebt er aber einige nervige Probleme, z.B. hatte ich keinen unbeabsichtigten "Drag" mehr, das flickern ist weg. Man braucht auch keine Angst haben, libxcb-1.11 hat den erwähnten Commit (seit August 2.14), das ist bei Gentoo stable.
Ich denke ich werde anregen, Threaded Mesa für qtgui:5 (in Gentoo) anzumachen.

schmidicom · Post by **schmidicom** » Wed Mar 25, 2015 1:16 pm

Falls jemand noch einen weiteren Grund sucht den neuen KDE auszuprobieren oder schon jetzt umzusteigen hier wäre einer:
https://bugs.kde.org/show_bug.cgi?id=324975
Denn wie es aussieht wird dieser, für mich zumindest, überaus lästige Bug in der 4er Version wohl nicht mehr gefixt...

Klaus Meier · Post by **Klaus Meier** » Wed Mar 25, 2015 5:21 pm

Die Hoffnung, dass bei KDE4 noch irgend etwas gefixt wird, die habe ich schon lange aufgegeben. 4.14 war doch eigentlich die bug-release, die nichts weiter als Bugs gebracht hat. Die es in 4.13 nicht gab. Ich sage nur Kmail.

ManfredB · Post by **ManfredB** » Thu Mar 26, 2015 12:24 pm

Ein weiteres Problem:

kde-apps/kcontrol is blocking kde-plasma/plasma-desktop-5.2.2
seltsamerweise auch plasma-desktop-5.2.1

Daher läßt sich kde-apps/kde-apps-meta nicht installieren,
denn kcontrol kann nicht ausgeschlossen werden.

Gruß
Manfred

Josef.95 · Post by **Josef.95** » Thu Mar 26, 2015 5:14 pm

ManfredB,
ja, das scheint so beabsichtigt zu sein. Schau warum kcontrol überhaupt benötigt wird (zb via "emerge -avc kcontrol" oder sofern noch nicht installiert maskiere kcontrol).

kde-apps-meta-14.12.3 würde hier kein kcontrol mit installieren wollen.

Klaus Meier · Post by **Klaus Meier** » Thu Mar 26, 2015 6:19 pm

Ich musste in der package.use folgendes setzen, damit es bei mir durchlief:

Code: Select all

kde-apps/kdebase-runtime-meta minimal
kde-apps/kde-l10n minimal
kde-apps/kdebase-kioslaves:4 minimal

Ich denke, das sollte dein Problem lösen.

Josef.95 · Post by **Josef.95** » Thu Mar 26, 2015 6:28 pm

Ah ja, oder wie schon mal empfohlen ein plasma Profil nutzen - dann sind die minimal UseFlags schon vom Profil her gesetzt :)
Schaut dazu auch im https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade

Klaus Meier · Post by **Klaus Meier** » Thu Mar 26, 2015 6:32 pm

Danke Josef, muss ich gleich mal schauen, kannte ich bislang noch nicht. Aber diese Einträge habe ich auch mit dem Plasma-Profil gebraucht. Kann natürlich sein, dass sich da etwas geändert hat, seit dem ich es das erste Mal aktiviert habe.

Aber der erwähnte Block sieht mir ganz danach aus.

Und nein, dieser Wiki-Eintrag ist auch nicht so der Hammer. Source irgendwas am Ende der make.conf ist schon seit ein paar Tagen nicht mehr so ganz aktuell. qt5 muss man auch schon seit Ewigkeiten nicht mehr unmaskieren. Und die Einträge mit dem minimal brauche ich immer noch. Da hat sich nichts geändert.

Josef.95 · Post by **Josef.95** » Thu Mar 26, 2015 6:51 pm

Klaus Meier,
ja ok, der Plasma_5_Upgrade Artikel ist noch längst nicht fertig - es ist eher ein erster Anfang.
Beachte das dort von einem stable System ausgegangen wird - sprich der layman source Eintrag und auch das qt5 UseFlag demaskieren ist so wie im Wiki beschrieben schon ok :)

Klaus Meier · Post by **Klaus Meier** » Thu Mar 26, 2015 7:30 pm

Nun ja, also zum einen, warum sollte man von Stable ausgehen, wenn man etwas Experimentelles nutzen will? Das passt für mich einfach nicht zusammen. Wer kein Testing will, was will der mit Overlays? Und ja, ich habe mir Dinge hart erarbeitet. Habe wochenlang irgend etwas mit irgend welchen Flags kompiliert, bis es bis mir lief. Man muss immer noch massiv etwas in der package.use setzen. Auch mit dem Plasma Profil. Das ist für mich auch kein Problem. Aber darauf sollte so ein Artikel eingehen.

Diese minimal sind nun mal nötig, sonst geht nichts. Und das sollte man vielleicht im Profil oder im Wiki berücksichtigen. Sonst hätte es ja das Posting von ManfredB nicht gegeben.

franzf · Post by **franzf** » Thu Mar 26, 2015 8:30 pm

Klaus Meier wrote:Das passt für mich einfach nicht zusammen. Wer kein Testing will, was will der mit Overlays?

Meinst du das wirklich so konsequent wie du es vorträgst?
Gründe für Overlays gibt es nämlich viele. Manche devs fügen Paketen nette Erweiterungen hinzu (danke mv!). Oder es sind ambitionierte Projekte wie proaudio, die halt auch einiges patchen (müssen). Oder es gibt mal (wieder) keinen offiziellen Maintainer, so dass ebuilds zwangsläufig in Overlays verwaltet werden müssen. Und das ist manchmal durchaus komplex, also nicht mit nem einfachen ebuild-kopieren ins eigene lokale overlay getan.

Josef.95 · Post by **Josef.95** » Thu Mar 26, 2015 8:46 pm

Klaus,
wie gesagt, der Wiki-Artikel ist noch längst nicht fertig - es ist ein erster Anfang..
Ich denke kein Wiki Artikel geht davon aus das man global testing setzt - das tut normal niemand.

Schau doch auch mal ins plasma Profil rein
Zb

Code: Select all

# Allow certain KDE 4 components to be coinstalled with Plasma 5          
<dev-util/kdevelop-4.8.0 -gdbui                                           
kde-base/baloo minimal                                                    
kde-base/kactivities minimal                                              
kde-base/kde-meta minimal                                                 
kde-base/kdeartwork-meta minimal                                          
kde-base/kdebase-kioslaves minimal                                        
kde-base/kdebase-meta minimal                                             
kde-base/kdebase-runtime-meta minimal

(Auszug)

Oder auch zum qt5 Use mask

Code: Select all

# until Qt5 is stable
qt5

(Auszug)
usw

mv · Post by mv » Fri Mar 27, 2015 8:28 am

Klaus Meier wrote:warum sollte man von Stable ausgehen, wenn man etwas Experimentelles nutzen will?

Weil man vielleicht nur in bestimmten Bereichen etwas Experimentelles will. Gerade bei Desktops will man vielleicht gerade mal nur die neuen Spielereien probieren, ohne deswegen zu riskieren, sein gesamtes rechtliches System instabil zu machen. Oder noch wichtiger: Da unstable Pakete wesentlich häufiger Version-Bumps erfahren, will man nicht unbedingt die Compilationsrate verdrei- oder vierfachen, nur weil man eine Spielerei vorzeitig testen will.

mv · Post by mv » Fri Mar 27, 2015 8:33 am

franzf wrote:Manche devs fügen Paketen nette Erweiterungen hinzu (danke mv!)

Schmeicheleien höre ich natürlich immer gerne

(Allerdings muss ich korrigieren: Ich bin kein (Gentoo) dev; ohne intensives IRC geht das nicht, und dafür habe ich schlichtweg keine Zeit. Zum Glück gibt es Remote-Maintainen und Overlays.)

Klaus Meier · Post by **Klaus Meier** » Fri Mar 27, 2015 8:39 am

Klar, so weit so gut. Aber warum werden dann die Punkte, die absolut wesentlich sind, ohne die gar nichts geht, egal ob Stable oder Testing, nicht erwähnt? Ich habe es hier doch mal vor geraumer Zeit zusammengeschrieben, was man so braucht, um es ans Laufen zu bekommen.

ManfredB · Post by **ManfredB** » Fri Mar 27, 2015 9:25 am

Nun muß ich doch berichten, was ich angestellt habe.

1. Immer wieder kam in der build.log von plasma-desktop-5.2.2 etwas von cmake,
was ich nicht verstanden habe.
Heute habe ich wieder layman -S und emerge --sync laufen lassen, dann emerge -avuDN world.

Dabei kam die Meldung: cmake hat falsche Einstellung: qt4/qt5 - nur eines von beiden.
Ich habe mich für qt4 entschieden, dann konnte ich cmake re-emergen.

2. Mein Versuch, plasma-desktop zu installieren, scheiterte erneut, ich habe die sehr lange
Darstellung durchlaufen lassen, am Ende wurde ein Konflikt aufgezeigt, der knetattach betrifft.
Und zwar unter /usr/share/doc/HTML/en eine png u.a. - die habe ich einfach gelöscht,
um zu sehen, was dann passiert.

Und siehe da: nun wurde plasma-desktop ohne weitere Fehlermeldung installiert.

Fazit:
Zwar lassen sich nicht alle Blocks und sonstige Fehler so ohne weiteres auflösen,
aber in diesem Falle war genaues Hinschauen doch die Lösung.

Danke für die Diskussion über mein ursprüngliches Problem, kcontrol betreffend.

Klaus Meier · Post by **Klaus Meier** » Fri Mar 27, 2015 9:30 am

Wenn es ohne irgendwelche Probleme perfekt laufen würde, dann wäre es nicht mehr in einem Overlay. Wer so etwas nutzt muss sich darüber im klaren sein, dass da noch Handarbeit gefragt ist.

Yamakuzure · Post by **Yamakuzure** » Fri Mar 27, 2015 1:58 pm

Klaus Meier wrote:Die Hoffnung, dass bei KDE4 noch irgend etwas gefixt wird, die habe ich schon lange aufgegeben. 4.14 war doch eigentlich die bug-release, die nichts weiter als Bugs gebracht hat. Die es in 4.13 nicht gab. Ich sage nur Kmail.

Aus reiner Neugier: Was ist denn mit kmail?

Ich benutze das seit Jahren, und hatte noch *nie* Probleme. (Außer ein Mal, weil ich zu faul war, die Migrationsanleitung zu lesen.)

Es kann doch nicht sein, dass gerade bei mir, der hoffnungslos stable/keyworded/masked vermischt, alles immer so reibungslos läuft Dazu habe ich Krempel aus 11 Overlays mit drauf, eineige Live Ebuilds, und baue alles mit gcc-4.9.2-r100 aus dem mgorny overlay.

Gut, ich habe nur zwei E-Mail Konten.
Ein Mal POP3 zu GMX, und ein IMAP zu unserem internen Exchange.
Aber nirgends irgendwelche Fehler. (Konfigurationsprobleme meinerseits einmal ausgeschlossen.)

Oder bin ich einfach zu blind einen offensichtlichen Fehler aus reiner Gewohnheit zu sehen? daher meine Frage was denn mit kmail sein soll.

Zu info: Hier ist kmail-4.14.3 installiert. Und das gesamte kde Gedöns habe ich seit kde-4.3 immer auf dem aktuellsten nicht-live Stand.
Einzige Ausnahme: .0-Versionen überspringe ich immer.

Zu dem Bug 324975: Das betrifft nur PulseAudio mit experimentellem Phonon und VLC-Backend? Tolle Regression.

Yamakuzure · Post by **Yamakuzure** » Fri Mar 27, 2015 2:16 pm

Klaus Meier wrote:Wenn es ohne irgendwelche Probleme perfekt laufen würde, dann wäre es nicht mehr in einem Overlay. Wer so etwas nutzt muss sich darüber im klaren sein, dass da noch Handarbeit gefragt ist.

Nicht unbedingt.
Für viele Dinge gibt es schlicht keine Devs, die es in den Portage Tree übernehmen können.
Und Leute wie ich (oder mv, (falls ich mich mal so weit aus dem Fenster lehnen darf, Martin)) haben einfach nicht die Zeit offizielle Gentoo-Developer zu werden.

Beispiele:

sys-block/zram-init : Die aktuelle Version findest du im mv Overlay. Diese wird, sobald Zeit ist, in den Portage Baum übernommen.
sci-misc/boinc : Die aktuelle Version findest du im seden Overlay. Irgendwann kommts auch in Portage an.
media-libs/allegro : Ebenso. Absolut stabil in der aktuellen Version, aber (noch) nicht in Portage.
sys-fs/squashmount : Absolut Zuverlässig. Aber nur im mv Overlay zu haben.
dev-util/nvidia-cuda-toolkit : Die aktuelle Version läuft seit Jahren problemlos mit gcc-4.9. Aber da nvidia offiziell nur gcc-4.8 unterstützt, kann der Maintainer das unmöglich freipatchen. Das ebuild im seden overlay schon.
app-portage/ufed : Die aktuelle Version lag bei mir 2 Wochen rum, bevor mein Proxy Zeit hatte, diese in den Portage Baum zu integrieren.
Die Live-Ebuilds aus dem Bumblebee Overlay verwende ich seit bald einem Jahr. Ohne Probleme.
net-mail/davmail-bin : Auch aus dem seden Overlay. Verwende ich seit Jahren, und Kalendar hat damit meine Exchange-Kalender bislang nicht zerlegt.
sys-kernel/geek-sources aus dem init6 overlay verwende ich seit Jahren. Ohne Probleme.
app-office/taskcoach ist im seden Overlay version 1.4.2, im Portage Baum: 1.3.40. Steinalt. Ich habe immer die aktuellste Version aus dem Overlay, und noch nie Probleme gehabt.
sys-devel/gcc-4.9.2-r100 : Alternatives ebuild aus dem mgorny overlay. Keine Probleme hier. Seit Monaten.
kde-misc/smooth-tasks-flupp aus dem seden Overlay tut hier schon seit KDE-4.5 seine Dienst.

Du siehst, die Annahme, dass alles, was in einem Overlay steckt, instabil und gefährlich sein muss, kann so nicht ganz stimmen.

Klaus Meier · Post by **Klaus Meier** » Fri Mar 27, 2015 2:40 pm

Also Kmail und alles, was mit Kdepim zu tun hat, lief als KDE 4.13 einfach traumhaft. Und beginnend mit KDE 4.14 wollte Kmail einfach keine Mails mehr abrufen. Frag mich jetzt nicht nach Details, das ist schon ein paar Tage her. Mit der Suchfunktion wirst du bestimmt einiges dazu finden. Auf alle Fälle hat KDE 4.14 in seiner ersten Version absolut nichts anderes als Bugs im Vergleich zu 4.13 gebracht.

Um dann in der aktuellen Version genau wieder da zu sein, wo 4.13 schon war. Oder kennst du irgend etwas, was bei 4.14 besser ist, als es bei 4.13 war? Und dafür haben sie drei Versionen gebraucht. Um wieder da zu sein, wo man mal war.

Yamakuzure · Post by **Yamakuzure** » Fri Mar 27, 2015 3:31 pm

Klaus Meier wrote:Also Kmail und alles, was mit Kdepim zu tun hat, lief als KDE 4.13 einfach traumhaft. Und beginnend mit KDE 4.14 wollte Kmail einfach keine Mails mehr abrufen. Frag mich jetzt nicht nach Details, das ist schon ein paar Tage her. Mit der Suchfunktion wirst du bestimmt einiges dazu finden. Auf alle Fälle hat KDE 4.14 in seiner ersten Version absolut nichts anderes als Bugs im Vergleich zu 4.13 gebracht.

Um dann in der aktuellen Version genau wieder da zu sein, wo 4.13 schon war. Oder kennst du irgend etwas, was bei 4.14 besser ist, als es bei 4.13 war? Und dafür haben sie drei Versionen gebraucht. Um wieder da zu sein, wo man mal war.

Ach da liegt der Hase im Pfeffer!

Ich überspringe die .0 Versionen genau deshalb. Sie machten immer gerne Probleme. Meine Erste war somit 4.14.1.

Und naja, aus dem Stehgreif fällt mir nichts ein, was in 4.14 besser sein sollte als in 4.13. Ist auch schon etwas her.

Aber was solls, KF5 ist ja immerhin auf einem guten Weg.

Wie stehen da eigentlich die Wetten wann sich ein Umstieg lohnt?

Klaus Meier · Post by **Klaus Meier** » Fri Mar 27, 2015 3:58 pm

Ok, in Bezug auf die Vergangenheit sind wir uns einig....

In Bezug auf die Zukunft: In 6 Monaten ist es reif für die Hardcorefraktion. In 12 Monaten ist es reif für Testing. Da wird mal wieder viel zu viel Druck gemacht. War bei KDE4 irgend wie das gleiche. Jeder wollte es unbedingt haben und als er es dann hatte, dann sagte er, taugt nichts. Bis das komplett mit KdePim im Testing ist, 12 Monate ab jetzt.

Klaus Meier · Post by **Klaus Meier** » Mon Apr 06, 2015 7:26 am

Für Plasma habe ich jetzt auch die optimale Lösung gefunden. Bitte nicht das Set installieren, das zieht immer Bluetooth mit rein, egal ob man es will ober nicht. Die Lösung lautet

Code: Select all

kde-plasma/plasma-meta

Damit bekommt man ein vollständiges System.