Kein Start ohne Qt 5.15 (bekomme aber nur 5.12)
Closed this issue · 17 comments
Hi,
mit der neuen Qt Version 5.15 habe ich ziemlich Probleme. Kleiner Brauhelfer startet nicht, weil ich nur 5.12 installiert bekomme. Die 5.15 scheint nicht in den offiziellen Paketquellen enthalten zu sein und wird (wohl auch deswegen) nicht beim ausführen von dpkg als Abhängigkeit gezogen. Ich weiß leider nicht, wie ich 5.15 bekomme (ohne qt.io Account).
System: Linux Ubuntu 20.04, x86_64
Ich habe:
- Download von
kbh2_v2.3.1_linux_x64.deb - Installieren des Pakets mit
sudo dpkg -i kbh2_v2.3.1_linux_x64.deb - Installieren von Qt5 mit
sudo apt install qt5-default - Installieren von pyqt5 mit
pip3 install pyqt5 - Installieren von qtchooser mit
sudo apt install qtchosser - Ausführen:
qmake --version
QMake version 3.1
Using Qt version 5.12.8 in /usr/lib/x86_64-linux-gnu
- Starten vom Kleinen-Brauhelfer-2:
kleiner-brauhelfer-2: /lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.15' not found (required by kleiner-brauhelfer-2)
Einen offline Installer gibt es auf qt.io nur für 5.12
Grüße !
Michael
Schau dir folgendes Projekt an:
https://github.com/miurahr/aqtinstall
Damit solltest du es hinkriegen. Du musst aber selber schauen wie genau. Vergiss nicht die Zusatzpakete qtcharts qtwebengine mit zu installieren.
Wenn du es geschafft hast, wäre es nett die Lösung hier zu posten.
Sollte so etwas sein
pip install aqtinstall
aqt install 5.15.2 linux desktop -m qtcharts qtwebengine
Damit hat es geklappt (auch wenn ich es nicht auf einem wirklich frischen System getestet habe).
Als Bash Skript würde das Ganze so aussehen (Version ließe sich anpassen oder als $1 übergeben):
# Configure
VERSION='5.15.2'
QT_PATH="/opt/Qt"
# Location for logs and download files
mkdir /tmp/aqt
cd /tmp/aqt
# Install helper (https://github.com/miurahr/aqtinstall)
sudo pip install aqtinstall
# Install Qt
sudo python3 -m aqt install --outputdir ${QT_PATH} ${VERSION} linux desktop -m qtcharts qtwebengine
# Set ENV variables
export PATH=${QT_PATH}/${VERSION}/clang_64/bin/:$PATH
export QT_PLUGIN_PATH=${QT_PATH}/${VERSION}/clang_64/plugins/
export QML_IMPORT_PATH=${QT_PATH}/${VERSION}/clang_64/qml/
export QML2_IMPORT_PATH=${QT_PATH}/${VERSION}/clang_64/qml/Ich habe sudo verwendet, um in /opt schreiben zu können (das ginge auch anders) und da es systemweit installiert werden sollte. Wegen der ENV bin ich mir nicht sicher, wie persistent das ist und ob nicht die ersten beiden Variablen als Nutzer (nicht Entwicker) ausreichen würden. So läuft es aber wie gesagt.
Ich würde vorschlagen, dieses Snippet entweder in die Readme aufzunehmen oder (wenn das möglich ist) irgendwie in den dpkg prozess einzubauen. Das ganze als Helper-Skript mit auszuliefern ginge natürlich auch.
Für die erweiterten Readme's zeichne ich verantwortlich - Glossar (kommt), ToolTips, Braumagazin.
Da aktuell erweiterte Techniken für das Braumagazin anstehen, brauche ich als Nicht-Linux-Nutzer konkreten Input:
Was ist das Problem? (Warum muss man QT installieren? Warum welche Version?)
Was passiert?
Was ist der Hintergrund des Nichtstartens?
Wie wird es gelöst?
Ein paar Zeilen, auch nur Schlüsselwörter, Kurzform würden mir genügen. Wichtig ist, den Ablauf von Problemstellung bis zur Lösung nachvollziehen zu können.
Qt sorgt für nativ wirkende Fenster unter den verschiedenen Betriebssystemen. Es ist also immer Bestandteil des Programms (unabhängig vom OS). Ich glaube für die Windows-Binaries wird der Teil vom Code ebenfalls mit gepackt, während es bei Unix (Linux/Mac?) nur ein Binding ist. Oder @BourgeoisLab ?
Vom daher gehört es in die normale Installationsroutine eines jeden Linux (Mac?) Nutzers und ist weniger als Problem zu sehen.
Das eigentliche Problem ist, dass Qt nicht einfach zu installieren ist und es auch noch zig verschiedene Versionen gibt 🙄
Welche Version man installieren muss hängt am Programm und könnte sich auch nochmal ändern. Daher die Idee es vielleicht besser als Helper-Skript zum .deb zu legen.
Wie sich das unter Mac verhält kann ich ende der Woche auch nochmal testen.
Vor dem Hintergrund würde ich es in folgende Stichwörter zusammenfassen:
- Das Programm benötigt die Qt Version XXX (momentan 5.15) welche unter Linux (Mac?) meist manuell nachinstallieren werden muss.
- z.B. für Ubuntu 20.04 lässt sich dies einfach mit folgenden Aufrufen erledigen: (Code siehe oben)
Bei Windows, Mac und die portable Linux Version ist Qt mit gepackt. Es ist also keine manuelle Installation nötig.
Am einfachsten lässt sich Qt über den offiziellen Installer qt.io installieren. Allerdings ist dafür ein Account nötig.
Der Weg hier beschreibt eine inoffizielle installation von Qt. Deshalb will ich es nicht im dpkg integrieren. Ich muss auch zugeben, dass ich kein Linux Experte bin und ich mich da auch nicht gross einarbeiten will.
Ich würde die Diskussion einfach so lassen und wenn weitere Leute nach der Installation fragen, kann man auf dieses Thread verweisen.
Es wird übrigens keine Änderung der Qt Version mehr geben, weil die 5.15.2 die letzte verfügbare Gratisversion ist.
Qt sorgt für nativ wirkende Fenster unter den verschiedenen Betriebssystemen. Es ist also immer Bestandteil des Programms (unabhängig vom OS). Ich glaube für die Windows-Binaries wird der Teil vom Code ebenfalls mit gepackt, während es bei Unix (Linux/Mac?) nur ein Binding ist. Oder @BourgeoisLab ?
Das sagt mir jetzt leider nichts und beantwortet die Frage nicht. Warum musst Du QT installieren? Was mein nativ? Was ist Binding?
Vom daher gehört es in die normale Installationsroutine eines jeden Linux (Mac?) Nutzers und ist weniger als Problem zu sehen.
Das eigentliche Problem ist, dass Qt nicht einfach zu installieren ist und es auch noch zig verschiedene Versionen gibt 🙄
Welche Version man installieren muss hängt am Programm und könnte sich auch nochmal ändern. Daher die Idee es vielleicht besser als Helper-Skript zum.debzu legen.
Verstehe ich nicht: QT ist laut Deinen Worten doch Bestandteil vom KBH.
Wie sich das unter Mac verhält kann ich ende der Woche auch nochmal testen.
Vor dem Hintergrund würde ich es in folgende Stichwörter zusammenfassen:
- Das Programm benötigt die Qt Version XXX (momentan 5.15) welche unter Linux (Mac?) meist manuell nachinstallieren werden muss.
- z.B. für Ubuntu 20.04 lässt sich dies einfach mit folgenden Aufrufen erledigen: (Code siehe oben)
OK. Das ist klar uns nachvollziehbar. Unter Mac braucht man es meines Wissens nicht.
Es wird übrigens keine Änderung der Qt Version mehr geben, weil die 5.15.2 die letzte verfügbare Gratisversion ist.
Das ist erst einmal eine gute Nachricht, die Klarheit für das Versionenwirrwar schafft. Ist es eine schlechte für die Zukunft des KBH?
Das sagt mir jetzt leider nichts und beantwortet die Frage nicht. Warum musst Du QT installieren? Was mein nativ? Was ist Binding?
@BourgeoisLab hat diese Frage beantwortet. Qt ist eine Bibliothek die im Code des KBH genutzt wird. Es ist schwierig es näher zu erklären ohne sehr technisch zu werden (was hier auch nicht weiterhelfen würde). Qt ist eine Abhängigkeit. Es ist notwendig. So wie die Schriftarten für Word. Und nun wissen wir auch, es ist nur für das Linux Paket notwendig, da sonst integriert (genauer gesagt "hineinkopiert").
Sorry, ich wusste nicht, inwieweit du mit dem Code hier und Programmierung vertraut bist.
Das ist erst einmal eine gute Nachricht, die Klarheit für das Versionenwirrwar schafft. Ist es eine schlechte für die Zukunft des KBH?
Erstmal nicht. So lange keine Probleme mit der momentanen Version auftauchen kann man daran noch lange Freude haben ;)
Also: Vielleicht einen Hinweis dazu ins Readme? Sonst müssten alle erst ein Issue mit der Frage aufmachen (evtl. sich dafür auch erst einen GitHub Account machen) ?
Ich könnte auch anbieten diesen Punkt ins Readme zu schreiben. Ist ja GitHub 👍
Auf Linux gibt es immer noch die Möglichkeit die App-Image Version zu verwenden statt eines der Debian Pakete zu installieren. Nur die .deb Pakete benötigen die geforderten Qt Komponenten in der geforderten Version, die selbst in den aktuellen Non-LTS Releases von Ubuntu (21.04) nicht Standard sind. Technisch gesehen werden Qt-Funktionen die im .deb Paket zur Verfügung stehenden Programme über Funktionspointer in im Betriebssystem installierten Share Libraries aufgerufen, während die Qt-Funktionen bei der AppImage Variante im Programm selbst vorhanden sind.
Nachteil des App-Images: keine Einbindung in die Menu-Struktur (Gnome/KDE), keine Nutzung der normalen Linux-Directory Struktur. Da das AppImage sämtliche benötigten Qt-Bestandteile beinhaltet, ist das herunterzuladende App-Image mit derzeit 104 MB recht groß im Vergleich zu den .deb Paketen. Das Linux AppImage entspricht den Windows Portable Version Versionen, die .deb Versionen den Windows Setup Versionen.
Das AppImage startet auch auf allen Linux Distro's, die keinen Debian Paketmanager unterstützen (Arch-Linux plus Derivate, RedHat plus Derivate). Wobei auf diesen Plattformen in der Regel Mechanismen existieren, mit denen das .deb Paket dann trotzdem installiert werden kann. Aber es ist umständlicher und erfordert detailiertes Know How.
Die Nutzung ist denkbar einfach für jemand, der mit einer Linux-shell umgehen kann:
File aus dem Download-Verzeichnis in ein eigenes Verzeichnis kopieren, Executable-Flag setzten, starten
also:
mkdir ~/kleinerBrauhelfer
mv ~/Downloads/kleiner-brauhelfer-2-x86_64.AppImage ~/kleinerBrauhelfer
chmod +x ~/kleinerBrauhelfer/kleiner-brauhelfer-2-x86_64.AppImage
~/kleinerBrauhelfer/kleiner-brauhelfer-2-x86_64.AppImage&
während des ersten Starts vom kb-AppImage wird ein Verzeichnis ~/kleinerBrauhelfer/kleiner-brauhelfer-2-x86_64.AppImage.config angelegt, in dem sich alle Dateien, die normalerweise im Linux-Filesystem verstreut abgelegt werden gespeichert (z.B. die Vektorgrafik-Vorlagen der Etiketten).
Bis auf die fehlende Integration in dem GNOME Starter eine bequeme Lösung. Ich finde, beide Varianten sollten uns Readme 👍
Linux-User sind eine kleine und technisch bewanderte Fraktion. Bei GNOME Starter muss ich und viele andere passen - dafür ist dann Github da. Bitte um Verständnis, ich werde mich deswegen nicht in Linux und besonders in seine Begriffswelt einarbeiten. Allein beim Thema QT und Distributionen zeigt sich für den Außenstehenden, wie viele Stolpersteine es bei Linux gibt. Ich habe aber Verständnis, dass bei wiederkehrenden Fragen die Linux-Anwender Unterstützung bekommen, wenn die Anwender mir leicht verständliche Sätze zuschicken. Leicht verständlich meint, dass Linux-Neulinge die Lösung sofort nachvollziehen können, ohne eigens dafür Fachbegriffe googeln zu müssen. Die Sätze sollten dabei kurz und prägnant nach dem Schema Subjekt-Prädikat-Objekt sein. Bitte auch darauf achten, dass möglichst generell Linux erklärt wird und nicht eine bestimmte Distribution. Spezialfälle sind nicht im Interesse der Vielen. Generell bin ich offen Linux-Support anzusprechen, solange es im Hinblick auf andere Anwender nicht überhand nimmt. Das ist leider immer ein Abwägungsproblem.
Ich werde die readme bei gelegenheit erweitern und die alternative instsllationsmöglichkeit für qt beschreiben.
Wie man mit der appimage umgeht, gehört aber meiner meinung nach nicht ins readme. Das ist mir zuwenig kbh spezifisch. Beziehungsweise Linux Anwender grösstenteils bekannt sein.
In einem Abschnitt Installationsmethoden würde ich mir als Anwender kurz ein paar Punkte zu jeder Methode und System wünschen (also Win Setup, Win Portable, .deb, AppImage). Das sind zwei bis drei Spiegelstriche pro Methode. (Wie funktioniert das, was sind Vor- oder Nachteile)
Obwohl ich Linux Anwender bin, wusste ich z.B. noch nicht, wo das AppImage seine Daten ablegt.
Ich finde, hier sollte man schon eine kurze Anleitung bekommen, wie ich den KBH auf mein System bekomme. Bei anderer Software steht ja auch zumindest sowas wie "Machen Sie einen Doppelklick auf setup.exe" obwohl das für einen Windows User offensichtlich sein dürfte.
Das Qt Problem ist eher das Spezielle, was in FAQs ausgelagert werden kann. Es ist im weitesten Sinne von der Systemkonfiguration des Nutzers abhängig.
Bitte auch darauf achten, dass möglichst generell Linux erklärt wird und nicht eine bestimmte Distribution.
Dinge für Linux muss man immer anhand einzelner Distros beschreiben. Allgemeines Linux gibt es leider nicht. Es aber auf Ubuntu zu beschränken reicht meist. Der Debian Anwender weiß, dass es für ihn fast 1zu1 gültig ist und der (leidgeprüfte) ArchLinux Anwender weiß, wie er Sachen, die für Debian/Ubuntu/etc. für sich abändern muss, damit es unter Arch funktioniert.
Generell bin ich offen Linux-Support anzusprechen, solange es im Hinblick auf andere Anwender nicht überhand nimmt.
Genau, wir sind da einer Meinung. Alle Fälle abzudecken ist wirklich zu weit weg vom KBH aber wenn die Lösung wie hier im Issue doch vorhanden ist, warum sollte man sie nicht auch einfach zugänglich machen? Dabei muss auch nicht der Author der Readme 100% verstehen, wie es funktioniert, solange die Lösung gemeinsam erarbwitet und mehrfach bestätigt worden ist. Soll heißen: @Rasinari du musst dir kein Linux System aufsetzen, um Support für Linux ins Readme aufzunehmen, das macht die Community für uns 😀
Zukünftige Probleme führen wieder zu Issues und die Lösungen daraus (sofern allgemein relevant) kommen ins FAQ.
Im September wird Teil 2 zum KBH im Braumagazin erscheinen. Wenn Du/Ihr da einen Absatz für Linux Ubuntu/Debian Installation (inkl. QT) schreiben wollt, vertrau ich mal auf die Aussage, dass man von Linux nichts verstehen muss und leite das dann an die Redaktion weiter. Sollte meines Wissens aber diese Woche sein, da die neue Ausgabe bereits in der Mache ist.
Im Braumagazin? Ich dachte nur ans Readme/Projektseite 😉
Ich denke es gereicht dem kleinen-brauhelfer-v2 zur Ehre, wenn mehrere Kanäle bespielt werden. Man erreicht damit ein disperseres Publikum, und nach all dem Engagement von Frédéric ist es mehr als fair und bedankt, wenn man etwas breiter streut :-)
Somit warte auf Deinen Input :-)
Readme angepasst mit e537412.