noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28954
Wohnort: WW
|
Hallo,
Hm, wäre imho eine sehr seltsame Koinzidenz, wenn es dort keinen Zusammenhang gibt, aber OK.
Klick' dich doch mal durch die Abhängigkeiten durch. Dann stellst du fest, dass libqt5core5a (5.12.8+dfsg-0ubuntu1) und libqt5core5a (5.12.8+dfsg-0ubuntu1) installiert werden. Aber es wird libshiboken2 >= 5.14.0 benötigt. Das ist das Modul was eine C++ API automatisch in eine Python API wrappt. Vielleicht kommt es daher. Wenn du es sehr genau wissen willst, könntest du noch den Maintainer des PySide-Pakets aus den Paketquellen anschreiben. Gruß, noisefloor
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! OK, könnte auch daher kommen. Ist aber auch nicht so relevant. Für mich bleibt unklar, wie und warum QT-Anwendungen aus den Quellen auf die /opt/-Qt-Dateien zugreifen können, wenn das Verzeichnis in der Umgebungsvariable gar nicht vorkommt; und die Anwendungen sind natürlich, anders als der selbstgebaute Falkon, auch nicht gegen diese Bibliotheken kompiliert worden. Wenn ich das verstünde, könnte ich nachvollziehen, dass es damit Probleme geben könnte... so long hank
|
Streifenschmerle
Anmeldungsdatum: 5. April 2006
Beiträge: 454
|
Kurzer Hinweis: Heinrich_Schwietering schrieb: Hi! Ich hatte versucht, mit
git clone git://anongit.kde.org/falkon.git
den Code von https://phabricator.kde.org/source/falkon/ zu ziehen,, wie dort angegeben ist. Ergebnis war allerdings leider:
Klone nach 'falkon' ...
fatal: Konnte nicht vom Remote-Repository lesen.
Bitte stellen Sie sicher, dass die korrekten Zugriffsberechtigungen bestehen
und das Repository existiert.
Das funktioniert nicht mehr, weil KDE Mitte dieses Jahres das Code-Hosting auf Gitlab (erreichbar unter invent.kde.org ) umgestellt hat und die alten Zugriffsmöglichkeiten generell nicht mehr funktionieren. Falkon ist hier gelandet: https://invent.kde.org/network/falkon/ Viele Grüße,
Jan
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
KaiserClaudius schrieb:
Das funktioniert nicht mehr, weil KDE Mitte dieses Jahres das Code-Hosting auf Gitlab (erreichbar unter invent.kde.org ) umgestellt hat und die alten Zugriffsmöglichkeiten generell nicht mehr funktionieren. Falkon ist hier gelandet: https://invent.kde.org/network/falkon/
Danke, ist bereits in den Kompilier-Artikel eingeflossen..., siehe Baustelle/Falkon/Kompilieren. Vielleicht kannst du das mal antesten, und mitteilen, ob es danach Probleme mit anderen KDE/Qt-Anwendungen gibt, falls du auf Kubuntu o.ä. unterwegs bist? so long hank
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Heinrich_Schwietering schrieb: Für mich bleibt unklar, wie und warum QT-Anwendungen aus den Quellen auf die /opt/-Qt-Dateien zugreifen können, wenn das Verzeichnis in der Umgebungsvariable gar nicht vorkommt; und die Anwendungen sind natürlich, anders als der selbstgebaute Falkon, auch nicht gegen diese Bibliotheken kompiliert worden.
Ich versuche es mal mit einem dummy-Beispiel: Angenommen du hast eine Bibliotheks-Funktion bool openUrl( const QUrl &url ) geschrieben, die mit der Bibliothek url12.so ausgeliefert wurde. Diese übernimmt eine URL als Argument und tut irgendwas, bevor sie wahr oder falsch zurückgibt. Jetzt arbeitest du weiter an deiner Bibliothek und änderst diese Funktion auf bool openUrl( const QUrl &url, bool privateSubWindow = false ), ergänzt also die Funktion um einen optionalen Parameter, der das öffnen in einem privaten Browser-Unterfenster ermöglicht. Das ganze veröffentlichst du als url13. Wenn das Programm jetzt keinen einzigen Funktionsaufruf mit ausdrücklich gesetztem privateSubWindow (true,false) enthält, funktioniert es mit beiden Bibliotheksversionen gleich, da in der neuen Biblitothek einfach „falsch“ als Standardargument ausgewertet wird. Setzt du aber explizit ein true oder false im Programm, werden 2 Argumente übergeben, womit die alte Bibliothek nichts anfangen kann. QUrl nana( "https://ubuntuusers.de" );
bool result = openUrl( nana ); // ← funktioniert in beiden Bibliotheken
bool resul2 = openUrl( nana, false ); // ← nur in der neueren Bibliothek möglich
Kompilierst du nun das Programm gegen die Version url13, funktionieren aber alle Aufrufe und es gibt keine Fehlermeldung. Läuft im System aber nur Bibliothek url12 und du greifst auf diese Funktion mit 2 Argumenten zu, fällt das Kartenhaus zusammen. Das Beispiel hinkt an mehreren Stellen, soll aber auch nur auf solche Fallstricke hindeuten. Der Punkt ist: Wenn du zwei Versionen einer Bibliothek verwendest, greift ein Teil (der mitgelieferte) auf die alte Bibliothek zurück, ein anderer Teil (den du manuell gegen das in /opt liegende kompiliert hast) auf die neuere. Die Ergebnisse werden weiterverarbeitet, müssen aber nicht zwangsläufig kompatibel sein, auch wenn jedes Teilprogramm in sich stimmig kompiliert werden konnte.
|
Streifenschmerle
Anmeldungsdatum: 5. April 2006
Beiträge: 454
|
Heinrich_Schwietering schrieb:
Danke, ist bereits in den Kompilier-Artikel eingeflossen..., siehe Baustelle/Falkon/Kompilieren. Vielleicht kannst du das mal antesten, und mitteilen, ob es danach Probleme mit anderen KDE/Qt-Anwendungen gibt, falls du auf Kubuntu o.ä. unterwegs bist?
Bei mir ist das Problem, daß mein Hauptsystem schon 20.10 ist und das Qt-PPA für Focal da ja vermutlich nicht funktionieren wird... Was relativ "einfach" ginge, wäre es auf einer schon vorhandenen 20.04-Testinstallation zu testen, aber es kann sein, daß mir da einiges durch die Lappen geht, da ich das nicht als Alltagssystem verwende. Viele Grüße,
Jan
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! @ChickenLipsRfun2eat Danke, dass du dir die Mühe machst, mir das näher zu bringen 👍. So grob hab ich wohl hoffentlich verstanden, worum es geht.
ChickenLipsRfun2eat schrieb:
Der Punkt ist: Wenn du zwei Versionen einer Bibliothek verwendest, greift ein Teil (der mitgelieferte) auf die alte Bibliothek zurück, ein anderer Teil (den du manuell gegen das in /opt liegende kompiliert hast) auf die neuere.
OK, so hatte ich mir das auch gedacht. K3b oder Kate aus den Quellen greifen also nicht auf die /opt-Biblotheken zurück. Die Ergebnisse werden weiterverarbeitet, müssen aber nicht zwangsläufig kompatibel sein, auch wenn jedes Teilprogramm in sich stimmig kompiliert werden konnte.
Aber hier frage ich mich auf den konkreten Fall bezogen doch, was denn ein Browser an Ergebnissen produzieren könnte, die von einer anderen Qt-Anwendungen weiterverarbeitet werden sollten - und damit dann auch, wo darin ein potentielles "Risiko" liegen soll. Wenn ich irgend eine Bibliothek kompilieren würde, die in anderen Programmen verwendet wird - OK, aber ein Web-Browser?... @ KaiserClaudius schrieb: Bei mir ist das Problem, daß mein Hauptsystem schon 20.10 ist und das Qt-PPA für Focal da ja vermutlich nicht funktionieren wird... Was relativ "einfach" ginge, wäre es auf einer schon vorhandenen 20.04-Testinstallation zu testen, aber es kann sein, daß mir da einiges durch die Lappen geht, da ich das nicht als Alltagssystem verwende.
Schade. Ja, das PPA ist nur für Focal konzipiert, gibt dort auch eines für xenial, aber nicht für neuere Versionen (und sowieso nur für LTS-Versionen). so long hank
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Heinrich_Schwietering schrieb: Aber hier frage ich mich auf den konkreten Fall bezogen doch, was denn ein Browser an Ergebnissen produzieren könnte, die von einer anderen Qt-Anwendungen weiterverarbeitet werden sollten - und damit dann auch, wo darin ein potentielles "Risiko" liegen soll. Wenn ich irgend eine Bibliothek kompilieren würde, die in anderen Programmen verwendet wird - OK, aber ein Web-Browser?...
Kann ich dir aus dem Stehgreif nicht beantworten. Dazu müsste ich mir den Quellcode zur Gemüte führen und welche Teile von bspw. KIO wirklich verwendet werden und welche Unterschiede die jeweiligen Versionen haben, wie die Plugins realisiert sind, etc. Plasma 5.20 hat ja seeeehr viele Änderungen mitgebracht. Generell verstehe ich aber deine Idee, dass ein Browser eigentlich™ „nur“ Webseiten anzeigen können muss. Das große ABER ist: HTML/XML-Parser, JavaScript, Passwort-Manager, Video-,Image- und PDF-Viewer, Python-Schnittstelle, Datei-Management wie Bookmarks, History, Ad-Blocker, usw. Das basiert alles auf dem KDE/Qt-Framework. Auch wenn man das nicht merkt, ein Webbrowser ist ein komplexes Teil. Deswegen muss Falkon selbst auch selten aktualisiert werden, das dient als Bindeglied zwischen den Schnittstellen. Genau deswegen kann einem das ja um die Ohren fliegen, wenn die zugrunde liegenden Komponenten unterschiedliche Bibliotheksversionen verwenden. Falkon selbst dürfte ziemlich unempfindlich sein.
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! OK, Danke, jetzt kann ich besser nachvollziehen, was das "potentielle" Risiko sein könnte. Heißt ja wohl auch: Je weniger KDE/Qt-Dinge auf dem Rechner sind, desto geringer das Risiko. dass es zu Problemen kommt 🤣 . Dann werd ich in den Kompilier-Artikel ein Hinweisbox mit Verweis hierher packen; vieleicht findet sich ja auch noch jemand mit Produktiv-KDE-System, die/der das einem Alltagstest unterziehen könnte. so long hank
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Heinrich_Schwietering schrieb: Heißt ja wohl auch: Je weniger KDE/Qt-Dinge auf dem Rechner sind, desto geringer das Risiko. dass es zu Problemen kommt…
Naja, es hat schon seinen Grund, dass Qt-lastige Programme/Distributionen zusehen ein aktuelles Qt im System zu haben. Die KDE-Community trägt ziemlich viel zum Sourcecode von Qt bei, weswegen es da nur logisch ist, dass Qt mit aktualisiert werden muss. Zudem gibt es monatlich ein Updatepaket für KDE/Plasma, das passt nur eben nicht zum LTS/STS-Konzept (das zwar größere Sicherheitslücken schließt, aber die wirklich nervigen Bugs drin lässt). Wenn du den Gedanken etwas weiterspinnst, hättest du vielleicht gerne die aktuellere Web- oder Multimedia-Engine auch für deine anderen Programme. Dann fängst du an das komplette Qt in Ubuntu auszutauschen…
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! So, ich denke, jetzt bin ich durch. PyPlugin funktioniert allerdings leider in keiner Version; im Paket aus den Quellen ist es nicht einkompiliert, Flatpak ebenfalls nicht, die selbstgebaute Version liefert Fehler dazu... Naja, wenn nichts dagegen spricht, verschiebe ich das die nächsten Tage. so long hank
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Heinrich_Schwietering schrieb: So, ich denke, jetzt bin ich durch. PyPlugin funktioniert allerdings leider in keiner Version; im Paket aus den Quellen ist es nicht einkompiliert, Flatpak ebenfalls nicht, die selbstgebaute Version liefert Fehler dazu...
Wenn bei der Kompilierung PySide2/Shiboken2/Python3 nicht gefunden wird, wird ohne Python-Support kompiliert. Ich würde den Einleitungs-Teil …Falkon jedoch ausschließlich auf Qt, hat keinerlei Abhängigkeiten von KDE…
vielleicht etwas ergänzen. Ubuntus falkon ist gegen die KF-Module kompiliert und hat diese damit auch als Abhängigkeit. Man kann Falkon allerdings auch ohne KDE-Frameworks kompilieren, aber nur manuell. WebKit wird auch nicht mehr verwendet, es kommt die QtWebEngine zum Einsatz. WebKit wird nur von manchen Abspaltungen noch angeboten, aber das ist im Ubuntuversum irrelevant (ich kenne das nur von Parabola, die bspw. den qutebrowser mit dem freien qt5-webkit anstatt der qt5-webengine ausliefern, Falkon bietet das aber imho nicht an). Die alternativen Browser-Projekte aus der Einleitung scheinen tot zu sein. Arora wird seit 2017 nicht mehr auf neuere Qt-Versionen ge-up-datet, rekonq ist sogar offiziell „unmaintained“. Ich verwende den qutebrowser, der allerdings ein PyQt-Projekt ist, kein WebEngine-Browser. Falkon ersetzt auch nicht den Konqueror, er existiert parallel und nutzt ebenfalls die qt5-webengine. Ich lese später noch weiter und melde mich, falls mir noch was auffällt 😉
|
Heinrich_Schwietering
Wikiteam
Anmeldungsdatum: 12. November 2005
Beiträge: 11290
Wohnort: Bremen
|
Hi! Danke, dass du noch mal draufschaust! ChickenLipsRfun2eat schrieb:
Wenn bei der Kompilierung PySide2/Shiboken2/Python3 nicht gefunden wird, wird ohne Python-Support kompiliert.
Ja, aber auch mit den Paketen (siehe Baustelle/Falkon/Kompilieren) funktioniert es nicht (jedenfalls nicht bei mir...) Ich würde den Einleitungs-Teil …Falkon jedoch ausschließlich auf Qt, hat keinerlei Abhängigkeiten von KDE…
vielleicht etwas ergänzen. Ubuntus falkon ist gegen die KF-Module kompiliert und hat diese damit auch als Abhängigkeit. Man kann Falkon allerdings auch ohne KDE-Frameworks kompilieren, aber nur manuell.
KF-Module heiß was genau -KDE-Framework-Module? Aber ansonsten eher was für den Kompilier-Artikel? WebKit wird auch nicht mehr verwendet, es kommt die QtWebEngine zum Einsatz. WebKit wird nur von manchen Abspaltungen noch angeboten, aber das ist im Ubuntuversum irrelevant (ich kenne das nur von Parabola, die bspw. den qutebrowser mit dem freien qt5-webkit anstatt der qt5-webengine ausliefern, Falkon bietet das aber imho nicht an).
Die alternativen Browser-Projekte aus der Einleitung scheinen tot zu sein. Arora wird seit 2017 nicht mehr auf neuere Qt-Versionen ge-up-datet, rekonq ist sogar offiziell „unmaintained“. Ich verwende den qutebrowser, der allerdings ein PyQt-Projekt ist, kein WebEngine-Browser.
Falkon ersetzt auch nicht den Konqueror, er existiert parallel und nutzt ebenfalls die qt5-webengine.
OK, die alte Einleitung hab ich etwas vernachlässigt, die Infos kann ich aber verwenden, und da noch etwa aufraümen Ich lese später noch weiter und melde mich, falls mir noch was auffällt 😉
Ok, THX! so long hank
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Heinrich_Schwietering schrieb: Wenn bei der Kompilierung PySide2/Shiboken2/Python3 nicht gefunden wird, wird ohne Python-Support kompiliert.
Ja, aber auch mit den Paketen (siehe Baustelle/Falkon/Kompilieren) funktioniert es nicht (jedenfalls nicht bei mir...)
Den anderen Artikel gucke ich mir auch gerne noch an. Ich habe gerade eine aktuelle Kubuntu 20.10 VM parat, kann das also auch ausprobieren.
KF-Module heiß was genau -KDE-Framework-Module? Aber ansonsten eher was für den Kompilier-Artikel?
Ja, das sind die Bibliotheken des KDE-Frameworks, die heißen so. Bspw. libkf5wallet-bin. Die Info war eher für dich, um die Einleitung anzupassen, du kannst sie aber gerne in den anderen Artikel einbauen, wenn das da passt. Mit apt depends falkon bekommst du die Abhängigkeiten des in universe enthaltenen Paketes. Da dort keine Python-Pakete auftauchen, nehme ich an, dass es ohne diesen Pluginsupport kompiliert wurde. Zum Artikel: Die Achtung-Box ist zwar korrekt, aber einmalig bei Qt-Paketen, oder? Müsste die nicht dann bei allen Qt-Programmen mit Internetanbindung erscheinen? Solche Anwendungen, wie bspw. VLC arbeiten ja auch mit Netzwerk-/Internet. Qt ist laut meinem 20.10 komplett in universe, wird aber mWn über Debian mit Sicherheitspatches versorgt. Ansonsten sind mir nur die englischen Menüs aufgefallen. Ich habe allerdings auch keine deutschen Sprachpakete installiert, denke aber, dass Falkon bereits übersetzt wurde…?
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53484
Wohnort: Berlin
|
ChickenLipsRfun2eat schrieb: Mit apt depends falkon bekommst du die Abhängigkeiten des in universe enthaltenen Paketes. Da dort keine Python-Pakete auftauchen, nehme ich an, dass es ohne diesen Pluginsupport kompiliert wurde.
Bitte nicht dependencies und make-dependencies in einen Topf werfen. Letztere findest du in der debian/control von http://archive.ubuntu.com/ubuntu/pool/universe/f/falkon/falkon_3.1.0-0ubuntu2.debian.tar.xz. Ich bin allerdings nur mit Handy unterwegs und hab da nix drauf, um reinzugucken. 😛 Edit: Oh, das war geschwindelt. Hab ja einen SSH-Client drauf. Hast aber recht, ist ohne gebaut. Build-Depends: cmake (>= 3.1),
debhelper (>= 11),
extra-cmake-modules (>= 5.27.0),
libjs-jquery,
libjs-jquery-ui,
libkf5coreaddons-dev,
libkf5crash-dev,
libkf5i18n-dev,
libkf5kio-dev,
libkf5purpose-dev,
libkf5wallet-dev,
libqt5x11extras5-dev,
libssl-dev,
libx11-dev,
libxcb-util0-dev,
pkg-config,
pkg-kde-tools,
qt5-qmake,
qtbase5-dev,
qtbase5-private-dev,
qtchooser,
qtscript5-dev,
qttools5-dev,
qttools5-dev-tools,
qtwebengine5-dev
|