KNX ETS 6.3.1 unter Linux mit Wine - ERFOLG! - mit Anleitung

[tobiasr]

In questing wurde libavcodec60 sowie ein paar weitere ffmpeg Pakete entfernt, umbenannt oder ähnlich. Daher bekomme ich jetzt es nicht installiert.

Ich muss mir die Tage dafür nochmal mehr Zeit nehmen. Die Frage ist auch, ob ich AKUT im KONKRETEN Fall ETS überhaupt libav benötige.

tr@xubuntu25:/etc/apt/sources.list.d$ sudo apt-get install  --ignore-missing  winehq-staging
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Auflösen von Abhängigkeiten… Fehler!
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 winehq-devel : Kollidiert mit: wine
                Kollidiert mit: wine-amd64
                Kollidiert mit: wine-i386
 winehq-staging : Hängt ab von: wine-staging (= 11.5~noble-1) soll aber nicht installiert werden
                  Kollidiert mit: wine
                  Kollidiert mit: wine-amd64
                  Kollidiert mit: wine-i386
E: Unable to satisfy dependencies. Reached two conflicting decisions:
   1. wine-staging-amd64:amd64=11.5~noble-1 is selected for install because:
      1. winehq-staging:amd64=11.5~noble-1 is selected for install
      2. winehq-staging:amd64=11.5~noble-1 Hängt ab von wine-staging (= 11.5~noble-1)
      3. wine-staging:amd64=11.5~noble-1 Hängt ab von wine-staging-amd64 (= 11.5~noble-1)
   2. wine-staging-amd64:amd64=11.5~noble-1 Hängt ab von libavcodec60 (>= 7:6.0)
      but none of the choices are installable:
      [no choices]
​

[RgSg86]

Hast du hier einen Tip, wie ich das auf einem jungfräulichen Ubuntu installiert bekomme?
Über

apt install --install-recommends winehq-staging

kommt noch 11.4

tr@xubuntu25:~$ cat /etc/apt/sources.list.d/winehq-questing.sources
Types: deb
URIs: https://dl.winehq.org/wine-builds/ubuntu
Suites: questing
Components: main
Architectures: amd64
​

Versuche mal den noble Branch statt questing:

sudo nano /etc/apt/sources.list.d/winehq-questing.sources

ändere "Suites: questing" zu "Suites: noble"

Dann:
sudo apt update
sudo apt install --install-recommends winehq-staging

Kann funktionieren, muss aber nicht

[tobiasr]

Wine Version 11.5

Hast du hier einen Tip, wie ich das auf einem jungfräulichen Ubuntu installiert bekomme?
Über

apt install --install-recommends winehq-staging

kommt noch 11.4

tr@xubuntu25:~$ cat  /etc/apt/sources.list.d/winehq-questing.sources
Types: deb
URIs: https://dl.winehq.org/wine-builds/ubuntu
Suites: questing
Components: main
Architectures: amd64
​

[RgSg86]

Mit der soeben veröffentlichten Wine Version 11.5 sind diverse Patches direkt in Wine eingeflossen, die den Installer/Manager weiter entschlacken. Weitere Patches direkt für Wine sind in Arbeit. Vielleicht ist Ende des Jahres nur noch ein Doppelklick auf die ETS Setup nötig und alles läuft einfach so durch, es bleibt dann nur noch ein Manager für Komfortfunktionen (Multiple parallele Installationen, DPI-Skalierung, Schriftart, USB-Regeln und Firewall-Regeln prüfen/anlegen).

Vielen Dank für das ganze Lob und auch einen großen Dank an alle Tester!

Nebenbei: Meine Windows-Partition hat sich nach dem letzten Windows Update mal wieder zerschossen, jetzt Fehler 0x69 beim booten, nicht auszuhebeln. Ich bereue nichts an dem Linux-ETS Projekt!

[sewi]

RgSg86 das Wissen welches du bei Wine hast, übersteigt das meine bei weitem, aber herzlichen Dank dass du dir diesen Aufwand antust - solche Projekte leben von Menschen wie dir. Ich persönlich vermute, dass das Umstellen von WPF auf Qt ein riesiger Aufwand ist, vor allem weil die ETS eine entsprechende Größe hat. Somit werden deine Änderungen wohl vorerst der einzige Weg bleiben, aber dafür ein Weg von dem langfristig viel profitiert, vorallem wenn der Support von Wine dadurch besser wird

Das mit den Schriftarten ist schon richtig so - wenn sie ähnlich genug aussieht, ist das auch relativ egal. Klar, der Benutzer kann tun was er will, finde es auch super dass du diese Option gibst.

Derzeit habe ich am Desktop kein Linux, aber gerade in der Zukunft kann es durchaus sein, dass ich auch direkt von deiner Arbeit profitieren werde - deshalb nochmals Danke, auch von mir.

[RgSg86]

Für mich als Laien: Was müsste die KNX-A eigentlich machen, damit die Patches nicht notwendig wären? Reicht da ein Exception-Handling, oder ist da mehr?

WPF = Windows Presentation Foundation ist das ganz große Problem in der aktuellen ETS.

Das ist Microsofts GUI-Framework für Desktop-Anwendungen. Das nutzt die ETS für eigentlich fast alles, Fenster, Ladebalken etc. Wine kann das ganze übersetzen, aber es ist halt aktuell nicht perfekt. Es fehlen schlichtweg noch ein paar Funktionen unter Wine, da muss man dann per Hand patchen. Ich entwickle seit sehr neustem hier und da direkt an Wine mit, daher weise auf die Fehler/Probleme hin, schreibe einen Patch und einen Test dazu, das wird sich dann angesehen und nach einer Prüfung in den nächsten Release gebaut ("gemerged"). Erste Änderungen von mir sind vielleicht schon in der Wine 11.5. Damit kann man sich die ganz dicken Bretter bei den ETS - Wine Anpassungen vielleicht zukünftig sparen. Lieber das Problem an der Wurzel anpacken als da fröhlich eine Stand-Alone Anpassung nur für die ETS bauen.

Aus meiner Sicht wäre ein guter Nachfolger für WPF für eine zukünftige ETS "Qt", das läuft eigentlich auf so ziemlich jedem OS. Ich komme gebürtig aus der Elektrotechnik, nicht aus der Informatik. Das meiste Wissen im Bereich meiner Programmierkünste ist angelesen und kommt von diversen kleinen Projekten die ich zum Teil beruflich, zum Teil spaßeshalber privat durchgeführt habe. Vielleicht stelle ich mir das mit einem Wegfall von WPF zu etwas Anderem hin in einer zukünftigen ETS 7 auch einfach zu leicht vor.

Zudem gibt es auch diverse Microsoft-Schriftarten, die Linux so nicht hat. Die Stellen an denen diese verwendet werden müssen angepasst werden, die fehlenden Schriftarten einfach so mitzuliefern ist rechtlich nicht in Ordnung. Der Benutzer selber kann das gerne tun (und im aktuellen Manager dann auch auf das Original ändern), aber ich werde das nicht automatisch mitliefern. Bei mir wird zu Beispiel die Microsoftschriftart "Segoe" auf die freie Noto Sans geändert und dem System dann vergaukelt, dass das Segoe wäre. Wer Frakturschrift oder Comicschriftarten haben will kann das aber auch gerne tun, alles was auf dem System installiert ist läuft grundsätzlich.

Hier und da gibt es noch ein paar kleinere Anpassungen.

[sewi]

Für mich als Laien: Was müsste die KNX-A eigentlich machen, damit die Patches nicht notwendig wären? Reicht da ein Exception-Handling, oder ist da mehr?

[traxanos]

Wie ich schon schrieb ist der KNXA das hier bekannt. Zumindest einzelnen Personen und die fanden es auch erstmal gut.

warum sollten sie auch was dagegen haben? Aber beim Thema Support sind sie halt raus. Das ist natürlich verständlich.

[RgSg86]

Nochmal aus der Nachtschicht:

Das mit den Hersteller-Addons, die für Windows gedacht sind, ist ein realistisches Problem. Auch in einer zukünftigen, nicht angekündigten ETS 7, zu deren Entwicklungszustand ich absolut nichts weiß, bliebe das Problem, dass ältere Addons nicht mehr einfach so laufen würden. Das Problem hatte ich jüngst beim debuggen des MDT Media Addons. Da werden Funktionen aufgerufen, die die ETS so gar nicht hat. Das wäre für jedes Addon jedes mal ein "Edge-Case", daher ein Problem, das nur unter bestimmten Umständen auftritt. Das ist zwar durchaus möglich, das die Hersteller (die es noch gibt) eine neue Version deren Addons veröffentlichen; fraglich ist aber, ob diese das tun, wenn der Markt klein ist oder das Produkt alt ist. Anpassungen durch die Community sind immer möglich, aber bei der Vielzahl der Addons nicht flächendeckend.

Für eine zukünftige ETS 7: Wenn keine alten Addons: kein Problem, das nativ für alle Plattformen anzubieten, auch mit wenig Aufwand. Wenn alte Addons dazu kommen: Problem.

Bei einer zukünftigen ETS 7 (unangekündigt, ohne das ich Infos dazu hätte) könnte man wirklich ohne Probleme einen Multi Plattform Support programmieren. Das Problem bleiben ältere Addons, die für Windows geschrieben wurden. Man könnte ab da einen harten Cut machen (kein Support für Addons von vor...), oder die Übersetzungsebene aktiv entwickeln. Klingt aber auch eher nach Comunity-Arbeit, da nicht Allgemein gültig eine Übersetzungsebene möglich ist.

Ich habe zwischenzeitlich diverse Bug-Fixes bei WineHQ eingereicht, so dass man einige spezielle Anpassungen zukünftig nicht mehr braucht. Einige landen davon auch im zukünftigen Build, andere sind noch in der Prüfung. Abgelehnt wurde bisher keiner.

Zielsetzung:

- ETS-Lizenz-Dongle-Support
- Feinschliff des GUI
- diverse Bugs identifizieren und abstellen
- populäre Addons unterstützen
- möglichst viel direkt in Wine implementieren (komplett vermutlich nicht möglich)

Perfekt wenn:
--> Doppelkick auf die jeweilge ETS Installer (.exe), Installation läuft durch, ETS startet, ist voll funktionsfähig.

Wichtig bleibt mir auch eine Unterstützung oder Duldung der KNX-A für mejn Projekt.

Wer Lust und das Können hat, hier aktiv mitzuwirken (abseits von einem Tester, sondern in den Code einsteigen kann/möchte), ist herzlich willkommen in dem Projekt.

[thengsty]

Das mögen viele einfach nicht wahr haben wollen, ist aber so.

Danke für die Aufklärung.

Wir vermüllen den Thread. Hier geht's weiter bei Bedarf.

[traxanos]

... was wiederum nur die Meinung einiger hier im Forum ist. Die man ja auch haben darf. Mehr als eine Meinung ist es aber eben auch nicht.

das hat nichts mit Meinung zu tun sondern ist technisch begründet. Das mögen viele einfach nicht wahr haben wollen, ist aber so.

Oder wie willst du fertige Windows Programme für die ets kompatibel halten wo es sogar die Hersteller nicht mehr gibt.

Übrigens gab es den Versuch ja schon mit der ets insde. Die war Multi os. Hat halt keiner genutzt weil zu abgespeckt und damit zu inkompatibel.

[sewi]

Rein rechtlich denke ich bin ich da auf der sicheren Seite. Die ETS selber fasse ich nicht an. Alle Dateien sind unangetastet innerhalb der ETS und entsprechen 1:1 einer Windowsinstallation, alle Patches greifen außerhalb. Das läuft alles mit Startscripten und Änderungen in der simulierten Windows-Registry unter Wine. Den Kopierschutz bzw. das Lizenzierungsystem mit Demo, Lite, Home und Pro fasse ich auch nicht an.

Das klingt schon mal gut - so wie es schilderst solltest du wirklich keine Probleme bekommen können.

[thengsty]

warum das nicht nur eine gut sondern auch eine dumme idee ist.

... was wiederum nur die Meinung einiger hier im Forum ist. Die man ja auch haben darf. Mehr als eine Meinung ist es aber eben auch nicht.

[traxanos]

also das klassische thema. das müssen wir hier nicht nochmal diskutieren. dazu gibt es hunderte beiträge hier im forum, warum das nicht nur eine gut sondern auch eine dumme idee ist.

[RgSg86]

Völlig realitätsfremd! Du kannst das mit Wine machen, weil du das privat machst. Die KNXA müsste aber die Haftung übernehmen etc. Für einen offiziellen Support ist sowas garnicht geeignet.

Ich denke du beziehst dich da auf die Wine - ETS6 Schiene. Das die KNX-A das nicht selber durchführen kann und will ist mir klar, eben aus Supportgründen. Aktuell sind in der ETS 6 zu viele spezielle Microsoft/Windows Sachen drin, die da raus zu lösen wäre vermutlich aufwändiger als das Ganze einfach neu zu entwickeln.

Ich spreche von einer zukünftigen ETS 7, die man direkt so bauen könnte, dass man die nur mit einem klick bei der KNX-A für alle möglichen Betriebssysteme kompilieren könnte. Das ist durchaus möglich und auch realistisch.