ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Naja, ich sehe das schon etwas problematischer, da die Integration u.a. auf KIO basiert. Da kann es Probleme geben, wenn das in unterschiedlichen Versionen vorliegt. Die fertigen, benötigten Pakete könntest du aber tatsächlich bei Neon abgreifen. Dort liegen ja alle nötigen Pakete, inkl. aktuellerem Qt. Wenn du Falkon nach Vorbild der KDE-Community bauen willst (kdesrc-build), dann musst du das in der Reihenfolge machen: sysadmin-repo-metadata
local
extra-cmake-modules
kcoreaddons
ki18n
karchive
kconfig
kdoctools
kwidgetsaddons
kwindowsystem
polkit-qt-1
kcodecs
kauth
kcrash
kdbusaddons
kguiaddons
kconfigwidgets
kitemviews
kiconthemes
kcompletion
kservice
sonnet
phonon
attica
breeze-icons
kglobalaccel
ktextwidgets
knotifications
kxmlgui
kbookmarks
kjobwidgets
kwallet
solid
kio
taglib
kirigami
kpackage
kparts
kactivities
kdeclarative
kidletime
kinit
kunitconversion
oxygen-icons5
syntax-highlighting
plasma-wayland-protocols
kdnssd
kitemmodels
kross
ktexteditor
kwayland
threadweaver
kded
kdesignerplugin
kemoticons
kfilemetadata
knewstuff
kpty
plasma-framework
baloo
bluez-qt
frameworkintegration
kactivities-stats
kcmutils
kdelibs4support
kdesu
kholidays
kimageformats
knotifyconfig
kpeople
kplotting
krunner
networkmanager-qt
prison
purpose
qqc2-desktop-style
syndication
falkon
modules
Das wiederum zerschiesst dir die anderen Anwendungen, die diese Grundlagen nutzen und am Ende landest du bei einem Selbstbau-Plasma und hast Neon neu erfunden 😉 Das KFrameWork hat seine eigene kleine dependency-hell… Vielleicht könntest du ja die fertig kompilierten Abhängigkeiten bei Neon laden und das ganze in ein Snap packen oder sowas.
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Häh? Verstehe nur noch Bahnhof... Was soll ich mit der Liste anfangen? Sollen das Pakete sein, oder Befehle oder was? 😲 Ich will kein KIO, und auch keine Pakete von Neon abgreifen, kein snap basteln, und auch nicht nach dem Vorbild der KDE-Community bauen. "Erstaunlicherweise" läuft Falkon bei mir, nachdem ich das Paket so wie ich es in Baustelle/Falkon/Kompilieren beschrieben hab, gebaut hab, ohne das ich prison, oder qqc2-desktop-style oder kplotting oder sonstwas installiert/ausgeführt oder was weiß ich damit gemacht habe. noisefloor meint, das sei eher ein Howto, warum verstehe ich auch nicht so ganz, aber egal. Vielleicht möchtest du ja, ChickenLipsRfun2eat, den Artikel zu Ende führen? Sorry, aber ich komme da nicht mehr hinterher. so long hank ,
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29067
Wohnort: WW
|
Hallo, so richtig richtig verstehe ich es auch nicht. Was ich aber glaube zu verstehen: KIO ist die API für alle möglichen Protokolle, inkl. HTTP und HTTPS. Die nutzt dann auch Falkon. Wenn Falkon aber eine andere Version von KIO benutzt als die KDE/Kubuntu Installation darunter, dann kann (muss aber nicht?) das Probleme geben. Nachtrag: der Vorschlag mit dem snap von ChickenLipsRfun2eat ist prinzipiell schon ein guter Weg, weil man dann sicher keine Versionskonflikte hat, weil das snap ja auf des KDE seiner Sandbox zugreift und nicht auf das des Systems. Man müsste halt nur ein besseres snap bauen als das, was bei snapcraft.io liegt, weil das ja gem. Bugreoprt nicht läuft? 2. Frage (vielleicht hätte ich die Baustelle vorher mal lesen sollen...): warum will man sich das mit dem selber kompilieren überhaupt geben, wenn es ein fertiges, aktuelles Paket bei flatpak gibt, was lt. Wiki auch läuft? Gruß, noisefloor
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! noisefloor schrieb:
Nachtrag: der Vorschlag mit dem snap von ChickenLipsRfun2eat ist prinzipiell schon ein guter Weg, weil man dann sicher keine Versionskonflikte hat, weil das snap ja auf des KDE seiner Sandbox zugreift und nicht auf das des Systems. Man müsste halt nur ein besseres snap bauen als das, was bei snapcraft.io liegt, weil das ja gem. Bugreoprt nicht läuft?
Wenn man das möchte und die Fähigkeiten dazu hat, kann man das sicher machen - ich kann es nicht. Das snap ist weiterhin nicht gefixt, es fehlt dort schlicht eine Datei, keine Ahnung, wie das zu fixen ist; in den snap-Ordner kommt man nicht so ohne Weiteres rein, wenn der erstmal auf dem Rechner ist, ansonsten könnte man die Datei ja darein kopieren, aber das ist wohl gegen das Prinzip der snaps 😉 2. Frage (vielleicht hätte ich die Baustelle vorher mal lesen sollen...): warum will man sich das mit dem selber kompilieren überhaupt geben, wenn es ein fertiges, aktuelles Paket bei flatpak gibt, was lt. Wiki auch läuft?
Das "aktuelle" Flatpak liefert zwar den aktuellen Falkon, der setzt dann aber auf QtWebEngine in Version 5.12.7 auf, was noch älter ist als das, was die focal-Quellen hergeben (steht auch in der Baustelle...), das wäre also den Teufel mit dem Belzebub auszutreiben 👿 so long hank
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29067
Wohnort: WW
|
Hallo,
Das "aktuelle" Flatpak liefert...
Ok. Dann sollte man IMHO im Artikel auch konkret darauf Hinweisen. Anscheinend ist es beim Flatpak ja dann auch so wie beim snap, dass sich keiner bemüßigt fühlt, das zu fixen. Gruß, noisefloor
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Heinrich_Schwietering schrieb: Vielleicht möchtest du ja, ChickenLipsRfun2eat, den Artikel zu Ende führen? Sorry, aber ich komme da nicht mehr hinterher.
Wenn du den Teil des selbst kompilieren meinst, das kann ich gerne mal in einer VM testen. Was die Bedienung und Plugins-Handhabe angeht, kann ich leider nicht wirklich was beitragen, Falkon ist für mich auch nur so ein „nebenbei“-Browser, wie Chrome/ium und Firefox — die benutze ich nur so, wie sie ausgeliefert werden. Zudem waren meine Versuche mit Snap bisher auch nur unbenutzbare Binärklumpen und da es immens Platz verbraucht, habe ich diese Versuche eingestellt. An deiner Kompilierung gibt es ja auch kein direktes Problem, du baust eben nur Falkon gegen das aktuellere Qt, ohne die KDE-Komponenten ebenfalls gegen das neue Qt zu bauen. Da KDE/Qt extrem eng verzahnt sind, kann es da evtl. Probleme geben. Kann ich aber mangels Erfahrung auch nicht abschätzen. Wenn ich bisher neue Qt-Versionen genutzt habe, dann habe ich alles, inkl. Abhängigkeiten kompiliert. Gerade KIO ist recht systemnah, da es alle Ein- und Ausgabekomponenten enthält (input/output).
|
tuxifreund
Projektleitung
Anmeldungsdatum: 7. November 2020
Beiträge: 1162
|
Würde es Sinn machen, wenn man nicht nur das Kompilieren in einen externen Artikel auslagert, sondern auch die anderen Installationsvarianten, also apt, snap, flatpak und den Artikel dann z.B. "Falkon/Installation" nennt?
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29067
Wohnort: WW
|
Hallo,
Würde es Sinn machen, wenn man nicht nur das Kompilieren in einen externen Artikel auslagert,
Nein, warum bzw. welchen Sinn soll das haben? Ohne sinnvollen Installationsweg käme der Artikel so oder so ins Archiv. Egal ob die Installation im Artikel oder einem Unterartikel beschrieben ist. So was gibt es zwar ab und an im Wiki wie Firefox/Installation. Das liegt da aber schlicht daran, dass es da so viele _funktionierende_ Variante beim Firefox wie Stable, Beta, Developer usw. gibt - und damit der Installationsartikel länger ist als viele andere Wikiartikel im gesamten ☺ Gruß, noisefloor
|
tuxifreund
Projektleitung
Anmeldungsdatum: 7. November 2020
Beiträge: 1162
|
noisefloor schrieb:
Würde es Sinn machen, wenn man nicht nur das Kompilieren in einen externen Artikel auslagert,
Nein, warum bzw. welchen Sinn soll das haben?
Ok.
So was gibt es zwar ab und an im Wiki wie Firefox/Installation.
Ich hatte bei dem Vorschlag an genau diesen Artikel gedacht. ☺ LG tuxifreund
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53625
Wohnort: Berlin
|
ChickenLipsRfun2eat schrieb: An deiner Kompilierung gibt es ja auch kein direktes Problem, du baust eben nur Falkon gegen das aktuellere Qt, ohne die KDE-Komponenten ebenfalls gegen das neue Qt zu bauen. Da KDE/Qt extrem eng verzahnt sind, kann es da evtl. Probleme geben.
Genau letzteres IST das Problem. Alle KDE-Bestandteile von 20.04 sind gegen Qt5.12.8 gebaut, das gesamte LXQt natürlich auch und ebenso andere Qt-Programme wie z.B. VLC. Wenn du jetzt Bestandteile anderer Qt-Versionen ins System bringst könnte bzw. wird das früher oder später zu Problemen mit den anderen Programmen führen.
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Bisher hab ich da noch nichts entsprechendes beobachtet; weder bei VLC noch bei K3b, aber viel anderes KDE-mäßiges hab ich auch nicht auf dem Rechner. Ich werds beobachten. Was genau meinst du, würde/wird(da bist du dir ja sicher) passieren? Gibt es "Präzedenzfälle", Dinge, auf die ich achten sollte? In den 20.04-Quellen sind die python3-qt-Pakete alle in Version 5.14.0, sollte es da nicht auch schon Probleme geben? Beim cmake-Aufruf für falkon werden Mindest-Versionen für verschiedene Qt-Sachen von 5.9 bis 5.15 ausgegeben. so long hank
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53625
Wohnort: Berlin
|
Heinrich_Schwietering schrieb: Was genau meinst du, würde/wird(da bist du dir ja sicher) passieren? Gibt es "Präzedenzfälle", Dinge, auf die ich achten sollte?
Programmabstürze, gar nicht erst startende Programme, nicht funktionierende Funktionen in Programmen, die zwar Starten, aber für die Funktion wiederum ein Programm nutzen, das nicht startet etc. pp.
In den 20.04-Quellen sind die python3-qt-Pakete alle in Version 5.14.0, sollte es da nicht auch schon Probleme geben?
Da find ich grade kein einziges, laut https://packages.ubuntu.com/search?keywords=python3-qt&searchon=names&suite=focal§ion=all haben die alle eigene, von der qt-Version unabhängige, Versionsnummern.
Beim cmake-Aufruf für falkon werden Mindest-Versionen für verschiedene Qt-Sachen von 5.9 bis 5.15 ausgegeben.
Im Prinzip KANN das alles abwärtskompatibel sein, MUSS es aber nicht. Wenn du mit Qt5.15 kompilierst heißt das noch lange nicht, dass ein für Qt5.12.8 kompiliertes Programm damit etwas anfangen kann, denn das ist nicht zwingend aufwärtskompatibel.
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! tomtomtom schrieb: Heinrich_Schwietering schrieb: Was genau meinst du, würde/wird(da bist du dir ja sicher) passieren? Gibt es "Präzedenzfälle", Dinge, auf die ich achten sollte?
Programmabstürze, gar nicht erst startende Programme, nicht funktionierende Funktionen in Programmen, die zwar Starten, aber für die Funktion wiederum ein Programm nutzen, das nicht startet etc. pp.
Klingt beeindruckend, aber ganz konkret hast du keine Beipiele dafür? In den 20.04-Quellen sind die python3-qt-Pakete alle in Version 5.14.0, sollte es da nicht auch schon Probleme geben?
Da find ich grade kein einziges, laut https://packages.ubuntu.com/search?keywords=python3-qt&searchon=names&suite=focal§ion=all haben die alle eigene, von der qt-Version unabhängige, Versionsnummern.
Da widerspreche ich dir - alle python3-pyside2.qt...-Pakete, die synaptic mir auflistet, haben Versionsnummer 5.14.0, der überwiegende Teil der python3-pyqt5.qt... Pakete haben Versionsnr. 5.14.1. Da waren deine Suchkriterien nicht ganz up-to-date, aber meine Aussage oben dazu auch nicht klar genug. Beim cmake-Aufruf für falkon werden Mindest-Versionen für verschiedene Qt-Sachen von 5.9 bis 5.15 ausgegeben.
Im Prinzip KANN das alles abwärtskompatibel sein, MUSS es aber nicht. Wenn du mit Qt5.15 kompilierst heißt das noch lange nicht, dass ein für Qt5.12.8 kompiliertes Programm damit etwas anfangen kann, denn das ist nicht zwingend aufwärtskompatibel.
Auch hier KANN, MUSS aber nicht. Das ist auch wenig konkret, würde aber für falkon ggf. erklären, warum einige Extensions im selbstgebauten Paket nicht funktionieren - kann dann daran liegen, dass im PPA ggf. nicht alles vorhanden ist, was Qt-Sachen zum Kompilieren von falkon gebraucht wird. Mir ist aber nicht ganz nachvollziehbar, wie Dinge, die in /opt/ liegen, und der Pfad /opt/... nicht in der PATH -Variable steht, Einfluss auf andere Programme haben können, die nicht explizit dort hingelenkt werden. Hab ich da das Prinzip der Umgebungsvariable nicht verstanden? Kann durchaus sein, aber ich war bisher davon ausgegangen (und hab auch entsprechende Erfahrungen gemacht ...) dass nur Dinge aus Pfaden, die in PATH stehen, auch verwendet werden können. so long hank
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29067
Wohnort: WW
|
Hallo, @Heinrich_Schwietering: das mit den Python Bindings sieht du falsch bzw. das ist nicht so, wie du denkst. PySide ist ein Python-Wrapper für die C++ API von Qt. PySide an sich "übersetzt" nur alles von Python nach C++ und gekehrt, mehr nicht. PySide läuft ohne Qt nicht. Das Basispaket von Pyside, libpyside2 (Paketbeschreibung) hat als Abhängigkeit die Qt ABIs 5.12.8 - also die Version von Qt, die in den Quellen ist. Warum PySide die Version 5.14 hat - keine Ahnung, hat jedenfalls nichts mit der Qt-Version zu tun. Zu opt: Ob ein ausführbares Programm in /opt liegt oder nicht ist erst mal egal. Relevant ist doch, auch welche Bibliotheken es zurück greift. Wenn das Programm auf die Systembibliotheken unterhalb von /usr oder wo auch immer zugreift, dann kann das Probleme geben. Kann, muss aber nicht. Ich halte es auch für ziemlich müßig, über mögliche Probleme zu reden. Ich sehe das aber auch so wie tomtomtom und ChickenLipsRfun2eat: wenn es zwei Versionen von Qt auf dem System gibt kann bzw. könnte das zu Probleme führen. Wenn man die nicht hat - gut. Kann ja auch sein, dass das nur bei total abgefahrenen Nischenfällen vorkommt. Die meisten Nutzer hatten wahrscheinlich auch - zum Glück - noch keines der Probleme, die in der Sektion "Problembehebung" in ??? Wikiartikeln aufgeführt sind. Trotzdem sind das ja Probleme, die irgendwie irgendwo irgendwann real waren. Der Wikiartikel zum Kompilieren von Falkon kann IMHO auch trotzdem ins Wiki - funktioniert ja scheinbar erst mal. Falls sich im Laufe der Zeit herausstellt, dass das einen Haufen Probleme macht und uu.de nur deswegen drei weitere, hochbezahlte Supporter für den KDE/Kubuntu Support einstellen muss 😉 , dann muss der Sinn des Artikels halt kurzfristig überdacht werden. Gruß, noisefloor
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
noisefloor schrieb: Hallo, @Heinrich_Schwietering: das mit den Python Bindings sieht du falsch bzw. das ist nicht so, wie du denkst. PySide ist ein Python-Wrapper für die C++ API von Qt. PySide an sich "übersetzt" nur alles von Python nach C++ und gekehrt, mehr nicht. PySide läuft ohne Qt nicht. Das Basispaket von Pyside, libpyside2 (Paketbeschreibung) hat als Abhängigkeit die Qt ABIs 5.12.8 - also die Version von Qt, die in den Quellen ist. Warum PySide die Version 5.14 hat - keine Ahnung, hat jedenfalls nichts mit der Qt-Version zu tun.
Hm, wäre imho eine sehr seltsame Koinzidenz, wenn es dort keinen Zusammenhang gibt, aber OK. Zu opt: Ob ein ausführbares Programm in /opt liegt oder nicht ist erst mal egal. Relevant ist doch, auch welche Bibliotheken es zurück greift. Wenn das Programm auf die Systembibliotheken unterhalb von /usr oder wo auch immer zugreift, dann kann das Probleme geben. Kann, muss aber nicht.
Damit verstehe ich es noch weniger: Die aus den Quellen installierten Qt-Programme greifen wohl kaum auf Dinge zurück, die in /opt liegen? Und: der selbstkompilierte Falkon liegt auch nicht in /opt, der Kompilierungsprozess greift aber explizit auf Bibliotheken zurück, die dort liegen, weil das angewiesen wurde. Ich halte es auch für ziemlich müßig, über mögliche Probleme zu reden. Ich sehe das aber auch so wie tomtomtom und ChickenLipsRfun2eat: wenn es zwei Versionen von Qt auf dem System gibt kann bzw. könnte das zu Probleme führen. Wenn man die nicht hat - gut. Kann ja auch sein, dass das nur bei total abgefahrenen Nischenfällen vorkommt. Die meisten Nutzer hatten wahrscheinlich auch - zum Glück - noch keines der Probleme, die in der Sektion "Problembehebung" in ??? Wikiartikeln aufgeführt sind. Trotzdem sind das ja Probleme, die irgendwie irgendwo irgendwann real waren. Der Wikiartikel zum Kompilieren von Falkon kann IMHO auch trotzdem ins Wiki - funktioniert ja scheinbar erst mal. Falls sich im Laufe der Zeit herausstellt, dass das einen Haufen Probleme macht und uu.de nur deswegen drei weitere, hochbezahlte Supporter für den KDE/Kubuntu Support einstellen muss 😉 , dann muss der Sinn des Artikels halt kurzfristig überdacht werden.
OK, Danke, dann kann ich da ja weitermachen, ohne dass es alles für die Tonne war. Erst wenn Probleme mit anderen Programmen auftreten sollten, kann ich sie aufnehmen... OT - "anscheinend", nicht "scheinbar" - scheinbar hieße hier, dass es nur den Anschein hat, dass das Kompilieren funktioniert, das in der Realität aber nicht so ist; anscheinend sagt nur aus, dass es für dich so aussieht, ohne das du es beschwören könntest 🤓 . so long hank
|