• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Plasma 5 für FreeBSD ist da

holgerw

Well-Known Member
Themenstarter #1
Hallo,

mithilfe des 2017Q1 branches unter Einpflegung der Plasma5 und qt ports von Areal51 konnte ich gestern mit poudriere fehlerfrei das komplette plasma5 bauen. Das war vor wenigen Monaten noch nicht der Fall.

Ich habe zwar die Pakete noch nicht installiert, aber schon der fehlerfreie Bau dieses großen Ungetüms macht mich da sehr zuversichtlich.

Feedback zum installierten Plasma5 reiche ich morgen nach.

An dieser Stelle schon mal ein großes Danke an Leute wie @tcb die damit sicherlich viel Arbeit haben.

Viele Grüße,
Holger
 

Fusselbär

Makefile Voyeur
#2
Von mir auch dankeschön für einpflegen der Qt Aktualisierungen in den Ports. :)
Anmerken möchte ich an dieser Stelle noch, dass der qtchooser mit folgenden Ports bei mir kollidierte:
Code:
qmake-3.3.8_2
qt4-dbus-4.8.7
qt4-help-tools-4.8.7
qt4-linguisttools-4.8.7
qt4-pixeltool-4.8.7
qt4-qdbusviewer-4.8.7
qt4-qdoc3-4.8.7
qt4-qmlviewer-4.8.7
qt4-rcc-4.8.7
qt4-uic3-4.8.7
qt4-xmlpatterns-tool-4.8.7
Es erwies sich bei mir hier auf meiner Installation als nötig diese Ports zunächst zu entfernen und später nach dem Upgrade die fehlenden Abhängigkeiten wieder zu installieren. Jedenfalls mit portupgrade, was ich immer noch verwende, funktionierte das so.
 

sterum

Well-Known Member
#3
qtchooser hat mir gestern das komplette KDE deinstalliert. ;)
Irgend ein Qt5 Port, den ich lokal mit poudriere baue, bringt den als Abhängigkeit mit und steht in Konflikt mit qt4-dbus. Als Workaround hab ich für's erste mal das lokale Repo deaktiviert.
 

Fusselbär

Makefile Voyeur
#4
Wenn man dort:
https://www.freshports.org/misc/qtchooser/
... mal das "This port is required by:" aufklappt, dann sieht man eine schön lange Liste. Die einzelnen Ports die ich entfernen musste, habe ich durch so lange einzeln austesten herausgefunden, bis sich qtchooser installieren ließ, vor dem upgraden der qt\* Ports auf dem alten Weg mit portupgrade.

Mein KDE ist die ganze Zeit dabei durchgängig als Desktop gelaufen. :)
Aber ich habe sicherheitshalber den xterm während des compilerns und installieren benutzt, anstatt die KDE Konsole.
 

holgerw

Well-Known Member
Themenstarter #5
Hallo @sterum hallo @Fusselbär

welche Ports nehmt Ihr als Basis? @foxit gab mir vor kurzem den Rat, zur Zeit beim Bau mit poudriere am besten als Ports-Grundlage den 2017q1 branch per svn auszulesen. Seither klappt das Bauen sehr reibungsarm. Und der Metaport x11/kde5 lies sich ohne Fehler mit den default-options bauen.

Viele Grüße,
Holger
 

Fusselbär

Makefile Voyeur
#6
Ich benutze die normalen Ports, also nicht Aera 51. So gibt es also noch kein KDE 5, aber ich bin gespannt darauf und kann es kaum noch abwarten. Weiß aber: gut Ding will Weile haben.
 

holgerw

Well-Known Member
Themenstarter #7
Hallo,

hier ein erstes Feedback:
Die Installation von x11/kde5 lief gut, keine Fehlermeldungen.

Die Stabilität: Hmmm, so la la. Da crasht noch so einiges, es sammeln sich core-Dateien an, das werde ich mir noch genauer anschauen.

Leider ist es zum produktiven Arbeiten für mich nicht zu gebrauchen. Digikam z.B. ist noch in Version 4 dabei, der Versuch, es zu installieren, würde mir den halben plasma5 Desktop deinstallieren. Warum geht das nicht parallel?

Zum Arbeiten werde ich vorerst weiterhin kde4 verwenden, das läuft doch sehr stabil.

Zum Testen werde ich diese Installation aber neben meinem Arbeitssystem belassen. Weitere Details dazu folgen.

Viele Grüße,
Holger
 

tcberner

Well-Known Member
#8
Moin moin

Jo, portmaster verschluckt sich an qtchooser, der ist neu eine runtime dependency von allen Qt-ports -- sprich portmaster Benutzer müssen sich wohl erstmal alle Qt-ports, welche eine Binärdatei in ${PREFIX}/bin installieren die nun von misc/qtchooser maskiert wird, deinstallieren, dann qtchooser installieren, und die anderen wieder installieren.

Die Stabilitätsprobleme kann ich selber nicht nachvollziehen (ich habs nun an die 3 Jahre als Standarddesktop hier) -- kactivitymanagerd crasht manchmal, aber das war schon in KDE4 Standardverhalten :P -- wenn Du da also genaueres sagen könntest, wäre das super.

Einen digikam-kf5 port findest Du hier https://github.com/thomaslegg/digikam-kf5 .



mfg Tobias
 

holgerw

Well-Known Member
Themenstarter #9
Hallo @tcb

danke für die Antwort. Dann werde ich nochmals meine poudriere Liste um allen kde4 Kram bereinigen, und den Port von digikam 5 dazu packen.

Wie bekomme ich eigentlich unter plasma5 Audio-Unterstützung? Ich möchte etwas gstreamer basiertes. Wie heißt da der Port?

Viele Grüße,
Holger
 

tcberner

Well-Known Member
#10
Versuchs mal mit multimedia/qt5-phonon4-gstreamer . Das ist das gstreamer backend für phonon. Alternativ gäbs noch das vlc backend.

mfg Tobias
 

h^2

hat ne Keule +1
Mitarbeiter
#11
Es sind doch jetzt schon eine Weile kf5- ports im offiziellen Branch. Die sind mir inzwischen aber nicht mehr wichtig. Mir wären da die Apps lieber und ich finde es auch ein wenig enttäuschend, dass FreeBSD nie auf die alleinstehenden KDE-Apps-Pakete umgestiegen ist, d.h. es gibt seit Jahren(!) keine Updates für die Apps. Stabil ist bei mir davon auch nur wenig, aber Bug-reports schreiben haben ich schon vor einer Weile aufgegeben, eben weil man von Upstream gesagt bekommt, dass man völlig veraltete Versionen hat :grumble:
 

holgerw

Well-Known Member
Themenstarter #12
Stabil ist bei mir davon auch nur wenig, aber Bug-reports schreiben haben ich schon vor einer Weile aufgegeben, eben weil man von Upstream gesagt bekommt, dass man völlig veraltete Versionen hat
Hallo @h^2

wäre dann der stabile 2017q1 branch plus plasma5 und qt5 von area51 keine Option für Dich, um ein lokales repo für eine plasma5 Installation mit poudriere zu bauen? Aktueller geht es zur Zeit kaum :) Und dann kommen die Bugreports beim Upstream auch gut an.

Klar, das alles zeitnah in den offiziellen Ports zu haben wäre besser. Aber vermutlich ist dafür das kde-FreeBSD Team zu klein (macht ja alles eine Menge Arbeit).

Viele Grüße,
Holger
 

Rakor

Administrator
Mitarbeiter
#13
Naja, also die meisten wollen halt ihre Software installieren und nutzen und nicht erst irgendwelche Entwicklungs-Repos irgendwo rein mergen um dann eine eigene Poudriere-Umgebung zu betreiben und dann noch frickeln bis alles zusammen passt.

Ich kann das gut verstehen. Ich habe auch nicht mehr die Zeit mich mit dem Bau meiner Umgebung zu befassen, sondern die muss funktionieren. KDE ist für mich auf BSD leider aktuell relativ tot. Das soll kein Vorwurf sein, klar ist das viel undankbare Arbeit und sicherlich die Manpower sehr überschaubar. Aber ich finde eben nicht, dass man sagen kann es gäbe ein aktuelles KDE unter FreeBSD, das ist einfach nicht wahr. Es existieren Entwicklungsbereiche und Bastelanleitungen.
 

h^2

hat ne Keule +1
Mitarbeiter
#14
Klar, das alles zeitnah in den offiziellen Ports zu haben wäre besser. Aber vermutlich ist dafür das kde-FreeBSD Team zu klein (macht ja alles eine Menge Arbeit).
Weiß nicht, wenn die Ports grundsätzlich mit den 4er Ports kompatibel sind (d.h. zumindest auf ports-infrastruktur eben sich nicht ebhindert, installation kann ja ruhig conflicten), dann verstehe ich nicht warum sie nicht in die ports aufgenommen werden. Dann gäbe es halt wirklich feedback von usern.
Oder pkg wird halt endlich so modular, dass man andere Repos nutzen kann, ohne dass es dauernd Konflikte gibt. Das geht bei anderen Systemen ja auch :-/
Ich weiß, viele Leute machen die Arbeit ehrenamtlich, ich bin da auch dankbar, aber ich denke, wenn die Prozesse anders gestaltet wären, wäre mit derselben Menge (bzw. Mangel) an Arbeit viel mehr Output drin.
Seit mein Studi-Leben vorbei ist und ich 40h die Woche beruflich Software schreibe, debugge et cetera, habe ich abends um 10 halt keine Lust mehr noch poudriere aufzusetzen und ich verstehe auch nicht, warum manche Sachen noch so kompliziert sind. Z.B. das Aktualisieren von Ports, die ich maintaine erlebe ich als zunehmend anstrengend. Wenn man dort modernes Tooling, mit git und PRs, und automatischer CI und so verwenden würde, würde ich definitiv viel mehr contributen (dazu muss man auch nicht zu github, das kann man auch mit gitlab und jenkins selber hosten, wenn man denn will).

edit: entschuldigt den leicht nörgelnden Tonfall, aber die Sachen brannten mir schon ne Weile unter den Nägeln :|
 

holgerw

Well-Known Member
Themenstarter #15
Hallo @Rakor

Naja, also die meisten wollen halt ihre Software installieren und nutzen und nicht erst irgendwelche Entwicklungs-Repos irgendwo rein mergen um dann eine eigene Poudriere-Umgebung zu betreiben und dann noch frickeln bis alles zusammen passt.
Klar, meine Zustimmung, ich gebe auch zu, dass ich dazu deshalb gekommen bin, weil ich seit Montagnachmittag mit einer fetten Erkältung zu Hause bin (sonst hätte ich dazu wegen meiner Arbeit erst einmal gar keine Zeit gehabt).

Hallo @h^2
ich habe Deine Beiträge gar nicht als Nörgeln und Vorwurf aufgefasst, sondern eher als Enttäuschung. Da Du Ports betreust, war das von mir mit dem Mergen der Ports als Vorschlag gemeint - klar ist das ein Workarround, der Zeit kostet.

Viele Grüße,
Holger
 

holgerw

Well-Known Member
Themenstarter #16
Hallo,

digikam5 baut nicht wegen fehlender Libs. Mittlerweile wird selbst mir das ein wenig zu frickelig. Und dann fehlen vermutlich die kipi-plugins5 .... und und und ...

Ich werde per svn den branch 2017q1 neu einlesen, da nichts dran basteln und ein kde4 bauen. Das läuft solide und rund - und dafür wieder mehr an meiner Dokumentation zu FreeBSD arbeiten. Sonst komme ich da irgendwie nicht richtig in die Pötte.

Mein Danke an das FreeBSD-KDE Team nmöchte ich jedoch wiederholen und hoffe, dass Ihr gut voran kommt.

Aber zum vernünftigen Mithelfen fehlt mir einfach noch zuviel KnowHow und auch Zeit.

Viele Grüße,
Holger
 

tcberner

Well-Known Member
#17
Es sind doch jetzt schon eine Weile kf5- ports im offiziellen Branch. Die sind mir inzwischen aber nicht mehr wichtig. Mir wären da die Apps lieber und ich finde es auch ein wenig enttäuschend, dass FreeBSD nie auf die alleinstehenden KDE-Apps-Pakete umgestiegen ist, d.h. es gibt seit Jahren(!) keine Updates für die Apps. Stabil ist bei mir davon auch nur wenig, aber Bug-reports schreiben haben ich schon vor einer Weile aufgegeben, eben weil man von Upstream gesagt bekommt, dass man völlig veraltete Versionen hat :grumble:
Da bist Du nicht der einzige... kommt bald [tm] -- btw, aktualisierte KDE4 Anwendungen gammeln auch brav im devel-repo rum :P



mfg Tobias
 

sterum

Well-Known Member
#18
Nachdem ich nun auch seit ein paar Tagen KDE5, oder wie immer das man jetzt nennt, verwende muss ich dem KDE-FreeBSD Team auch meinen Dank aussprechen. Bis auf einige Kleinigkeiten läuft es schon sehr rund. Lediglich das starten von plasma5 dauert extrem lange (30s). Wo kann man nachsehen an was es liegt?
Und sddm bringe ich auch nicht zum laufen. ( gehört ja eigentlich nicht zu KDE). Egal, verwende ich halt slim.
 

tcberner

Well-Known Member
#19
Du könntest mal die Ausgabe von startkde ansehen, ev siehst du dann wo er hängt -- sollte eigentlich nicht so lange gehen.
Ev läuft noch irgend eine kde4-Migration im Hintergrund bei dir.


mfg Tobias
 

holgerw

Well-Known Member
Themenstarter #21
Hallo,

falls noch jemand hier herein schaut - hier der aktuelle Stand:
Wichtig: Vor dem Bau den patch für devel/icu nicht vergessen, siehe:
https://www.bsdforen.de/threads/kde5-kann-keine-dateien-und-ordner-mit-umlauten-öffnen.33388/

- KDE5 baut komplett mit dem 2017Q1 branch
- german/kde-l10n baut
- digikam5.4 samt kipiplugins bauen
- diverse für mich relevante Desktopanwendungen (office, firefox, claws-mail, audacity, easytag, lyx) bauen

plasma5 läuft auf meinem Notebook mit Intelgrafik ordentlich flüssig.

Viele Grüße,
Holger
 

holgerw

Well-Known Member
Themenstarter #22
Ergänzung 1: Wenn mit head als Basis gebaut wird, müssen zur Zeit die Options von kio-extras bearbeitet werden, und samba entfernt werden, sonst wird es wegen eines fehlenden Ports zu samba nicht gebaut.
Ergänzung 2: Leider muss unter head devel/icu nach wie vor gepatcht werden, weil sonst in einige Programmen unter plasma5 Dateien und Ordner mit Umlauten nicht angezeigt werden. Mein head basiertes repo darf ich somit nochmal bauen.

Viele Grüße,
Holger
 

holgerw

Well-Known Member
Themenstarter #24
Bei mir hat es gereicht nur devel/icu neu zu bauen.
Okay, werde den Bau heute Abend mit dem Patch anstoßen, mal schauen, was dann alles neu gebaut wird.

Was mir im Vergleich zu 2017Q1 als Basis jedoch schon auffällt: Unter meinem Notebook mit Intel Grafik "fühlt" sich das mit head gebaute plasma5 deutlich flüssiger an.
 

tcberner

Well-Known Member
#25
Ergänzung 1: Wenn mit head als Basis gebaut wird, müssen zur Zeit die Options von kio-extras bearbeitet werden, und samba entfernt werden, sonst wird es wegen eines fehlenden Ports zu samba nicht gebaut.
Ergänzung 2: Leider muss unter head devel/icu nach wie vor gepatcht werden, weil sonst in einige Programmen unter plasma5 Dateien und Ordner mit Umlauten nicht angezeigt werden. Mein head basiertes repo darf ich somit nochmal bauen.

Viele Grüße,
Holger
Die kio-extras optionen sind nun wieder geflickt -- bzw somit auf 2017Q1 kaputt :D