phoenicis
phoenicis copied to clipboard
Exception on launching wine
Expected behavior
I build phoenicis from git-upstream, and create the flatpak package. Launching any app should work, for example xenon 2.
Actual behavior
An exception occurs, while trying to execute wine/wineserver This error does not occur on 5.0-alpha.2-release
Steps to reproduce
Build phoenicis via mvn clean package from upstream. Build the flatpak via flatpak-builder. Install the flatpak-package. Install for example xenon 2.
System information
- software version (git revision) of phoenicis and scripts repositories: git-upstream
- used operating system: Debian10
- used Java version: As packaged.
Here the exception below. The executable (wine and wineserver) is existing, and executable.
Exception Xenon 2:
[ERROR] org.phoenicis.multithreading.ControlledThreadPoolExecutorService (l.64) - Cannot run program "/home/wine/.Phoenicis/engines//wine/dos_support-linux-x86/4.0/bin/wineserver": error=2, Datei oder Verzeichnis nicht gefunden
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1128)
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)
at
Same exception on Dreamscapes(2):
[ERROR] org.phoenicis.multithreading.ControlledThreadPoolExecutorService (l.64) - Cannot run program "/home/wine/.Phoenicis/engines//wine/upstream-linux-x86/5.0.1/bin/wine" (in directory "/home/wine/.Phoenicis/containers/wineprefix/Dreamscapes2"): error=2, Datei oder Verzeichnis nicht gefunden
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1128)
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)
at
Hint in console inside flatpak container below. Seems it has anything to do with 32bit lib?
sh-5.0$ file /home/wine/.Phoenicis/engines//wine/dos_support-linux-x86/4.0/bin/wineserver /home/wine/.Phoenicis/engines//wine/dos_support-linux-x86/4.0/bin/wineserver: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=a69c2a80fcbefb6b70a85100700b674dc638ac83, not stripped sh-5.0$ sh-5.0$ file /lib/ld-linux.so.2 /lib/ld-linux.so.2: broken symbolic link to i386-linux-gnu/ld-linux.so.2
Could it be that you're missing some extensions? See https://github.com/PhoenicisOrg/phoenicis/blob/bd7055d0412f788acf7330af982ca2e75fda6ecc/.travis.yml#L55.
(especially org.freedesktop.Platform.Compat.i386/x86_64/19.08
)
Just checked myself. I get file not found for:
-
Xenon 2//drive_c/autoexec.bat
-
.Phoenicis/engines/wine/dos_support-linux-x86/4.0/bin/dosbox
However, that's regardless of flatpak or not. Please raise an issue in scripts or winebuild.
@plata I was now able to get it running. But my flatpak-issue is different from your dosbox-issue. I had to change the freedesktop dependencies back to 18.08 (from 19.08)
- org.freedesktop.Platform.Compat.i386
- org.freedesktop.Platform.Compat.i386.Debug
- org.freedesktop.Platform.GL32
Then I am able to install Xenon 2 with no errors. But I can still not run Xenon 2 --> Nothing happens. I was able to install and run other apps. (Dreamscapes)
That's interesting. Any ideas why 18.08 works but 19.08 not (I'm using 19.08 and it works for me)?
I had still Compat.i386 18.08 installed instead 19.08. So the whole i386-linux-gnu folder was empty. Flatpak makes no noise, just starts a broken incomplete app. Also I can uninstall the Compat-lib again, without any warn message.
Installing playonlinux does not install dependencies, in my case. Maybe this has to do with the local repo, where no dependencies are existing ... confusing.
Anyway, now it is also working on my machine with 19.08
I remember a discussion with the guys from flatpak where they explained why the extensions are not installed automatically. I cannot recall completely and maybe it changed in the meantime. In any case this question/problem should be raised for flatpak in my opinion. Can we close this?
Not sure, I still have a Problem with GL now.
Can install, but not run apps.
And when executing flatpak uninstall --unused
then flatpak wants to uninstall Compat.i386 again.
Only way for me is currently to use 18.08
I still try to find any reason for this behaviour.