Linux version of Logos Bible Software
Comments
-
I have uploaded wasta-logos-setup version 0.2.0 which adds the cabextract dependency, and also adds the wine 4.18 patch. So, at least for me on Ubuntu 18.04, with wine 4.18, everything appears to be working again. So, step 4.5 should be unnecessary, but let us know if otherwise!
In the future, if/when wine updates it will break again. So I recommend you disable the winehq repository (Software Settings > Other Software > UN-Tick the winehq source) until we can get the patch accepted into the mainstream wine repository. To prevent wine from updating and causing crashing, I could make it so that in the wasta-logos-setup install process it would disable the winehq repository. A user could manually re-enable it. But I am not sure if this would be too "heavy handed" or not. Let me know what you think of this option.
Rik
PS: @frank can you choose to "Show Details" of your crash and then look at the error? If you are getting something along the lines of a "System.AccessViolationException" then this is our original error and it means that your wine version isn't patched. I made a bit of an update to wasta-logos-setup that may address this problem by better detecting if wine needs patched and prompting for it. This is also in version 0.2.0, so let us know!
0 -
Rik Shaw said:
PS: @frank can you choose to "Show Details" of your crash and then look at the error? If you are getting something along the lines of a "System.AccessViolationException" then this is our original error and it means that your wine version isn't patched. I made a bit of an update to wasta-logos-setup that may address this problem by better detecting if wine needs patched and prompting for it. This is also in version 0.2.0, so let us know!
I didn't see that - I copied the details and posted it in my post above.
Update - I was just doing a complete fresh install of Kubuntu 18.04 and Logos got to about 90% of resources downloaded and dropped this error on me. Figured I would try going back to 18.04 and the install went smooth, log-in went smooth and then download crashed. Similar to my fresh install on 19.10 last night and it crashed during resource download and never would work again.2703.backtrace.txt
Logos 10 - OpenSuse Tumbleweed, Windows 11, Android 16 & Android 14
0 -
Frank, I think I've seen this bug... Can you run it from the terminal and share the output? For a workaround I think you need to choose to do a minimal install and then when it has successfully indexed the first time you can add the rest of your books. The terminal output would be really helpful. The backtrace less so. It would also be helpful to know roughly how big your library is by resource count?
Thanks
גַּם־חֹשֶׁךְ֮ לֹֽא־יַחְשִׁ֪יךְ מִ֫מֶּ֥ךָ וְ֭לַיְלָה כַּיּ֣וֹם יָאִ֑יר כַּ֝חֲשֵׁיכָ֗ה כָּאוֹרָֽה
0 -
Here's the output and maybe it is tied to trying a full install of the resources in one shot.... The first install I did that survived the upgrade all the way through 19.10 was minimal to begin, then once everything finished - I downloaded the rest of the resources and update to 19.04 afterward, then to 19.10.
Resources are a little over 4k
John Goodman said:Frank, I think I've seen this bug... Can you run it from the terminal and share the output? For a workaround I think you need to choose to do a minimal install and then when it has successfully indexed the first time you can add the rest of your books. The terminal output would be really helpful. The backtrace less so. It would also be helpful to know roughly how big your library is by resource count?
Thanks
Logos 10 - OpenSuse Tumbleweed, Windows 11, Android 16 & Android 14
0 -
John Goodman said:
Bill if you get it going on a chromebook then please document your steps and share... I'm sure there will be others who own chromebooks that would be interested.
I will do that, John. I will report back when I attempt this.
0 -
Now that we have Logos working on Linux, it would be great to have our own sub where users can post requests for assistance instead of continuing this very long thread which now is misnamed (we aren't going to get a Linux version of Logos -- at least based on Faithlife's public statements here and elsewhere). But, I figure Faithlife won't create a sub for us because it will imply that they will support what we are all doing. It would be natural for the development effort to continue in its own space, though.
0 -
So... I went through the whole process again...
The first download and install of the minimal resources went fine and indexed quite well. The indexing finished in comparable time to Windows. The second download of a little over 1 gig off resources did the same. A third download the program started downloading 15 gigs and it reached about 50% and crashed.
The program now opens and crashes within seconds of opening with the same error as above
Frank Sauer said:Here's the output and maybe it is tied to trying a full install of the resources in one shot.... The first install I did that survived the upgrade all the way through 19.10 was minimal to begin, then once everything finished - I downloaded the rest of the resources and update to 19.04 afterward, then to 19.10.
Resources are a little over 4k
John Goodman said:Frank, I think I've seen this bug... Can you run it from the terminal and share the output? For a workaround I think you need to choose to do a minimal install and then when it has successfully indexed the first time you can add the rest of your books. The terminal output would be really helpful. The backtrace less so. It would also be helpful to know roughly how big your library is by resource count?
Thanks
Logos 10 - OpenSuse Tumbleweed, Windows 11, Android 16 & Android 14
0 -
I may have found the cause of the error.... Having been through a couple Beta cycles in the past, I remembered similar behaviors when the old Libronix engine was left behind and all the indexing began.
One of the issues that would cause this typs of behavior was corrupt databases. I tried deleting everything out of the folding that holds the index files - didn't fix the problem.
I then tried cleaning out the Library Catalog folder - Sure enough that allowed the program to start and it did crash twice more, but each time clearing that folder allowed it to download more resources and index fine.
Right now, I have just two stubborn resources that say downloading, but do not seem to actually ever download. The index is rebuilding now.
Frank Sauer said:So... I went through the whole process again...
The first download and install of the minimal resources went fine and indexed quite well. The indexing finished in comparable time to Windows. The second download of a little over 1 gig off resources did the same. A third download the program started downloading 15 gigs and it reached about 50% and crashed.
The program now opens and crashes within seconds of opening with the same error as above
Frank Sauer said:Here's the output and maybe it is tied to trying a full install of the resources in one shot.... The first install I did that survived the upgrade all the way through 19.10 was minimal to begin, then once everything finished - I downloaded the rest of the resources and update to 19.04 afterward, then to 19.10.
Resources are a little over 4k
John Goodman said:Frank, I think I've seen this bug... Can you run it from the terminal and share the output? For a workaround I think you need to choose to do a minimal install and then when it has successfully indexed the first time you can add the rest of your books. The terminal output would be really helpful. The backtrace less so. It would also be helpful to know roughly how big your library is by resource count?
Thanks
Logos 10 - OpenSuse Tumbleweed, Windows 11, Android 16 & Android 14
0 -
It would be great to have a forum area for Linux!
0 -
@J. Erik
How did your attempt with Manjaro go? I've recently made the switch from Mint to Manjaro (Gnome) and will give it a good shot once I get my head around where to begin. [Y]
Husband, Dad, Expat to Northern Europe. I serve people, share hope, & write about simple theology for a messy life at genewhitehead.com.
0 -
Gene W. said:
How did your attempt with Manjaro go? I've recently made the switch from Mint to Manjaro and will give it a good shot once I get my head around where to begin.
Hi Gene
I failed to install winehq-devel. There is no such package in the Repositories or in the AUR. I tried to compile it but without success. So I installed mint 19.2 (=ubuntu 18.4). But I have some issues with installing .net 4.7.2. The installation quits with failure (winehq 4.18 and wasta 0.2). I decided to wait some month until our experts got run a new version of the wasta-setup. Btw. manjaro is really the faster and nicer linux.
Greetings
Dirk
0 -
Hi Dirk,
Thanks for that information. I'll also wait at this point too. Agreed, Manjaro has been great so far. So much that I'm not willing to step out of it just yet and will run Logos in a VM for now. Appreciate your attempts and sharing your insight from it.
Husband, Dad, Expat to Northern Europe. I serve people, share hope, & write about simple theology for a messy life at genewhitehead.com.
0 -
Due to wine versions changing and overwriting the necessary patch, it was discussed to bundle wine with the patch as part of wasta-logos-setup.
I have experimented with this and can make it work, BUT it adds 853MB of size to the package! I don't know of a smart way to bundle wine except for manually taking the entire /opt/wine-devel/ folder. I can't seem to split apart the amd64 pieces of it automatically, maybe I can manually remove them.
Regardless, even if I could remove all amd64 pieces, it would still be possibly 450MB of size to bundle wine. Opinions?
0 -
I've built debs for 4.18 both architectures and it comes to 191mb. I'll ping them across to you in an email.
גַּם־חֹשֶׁךְ֮ לֹֽא־יַחְשִׁ֪יךְ מִ֫מֶּ֥ךָ וְ֭לַיְלָה כַּיּ֣וֹם יָאִ֑יר כַּ֝חֲשֵׁיכָ֗ה כָּאוֹרָֽה
0 -
So, I finally had the time to sit down and go through the instructions provided here.
All I can do is parrot Anakin Skywalker from The Phantom Menace when he was testing his podracer: "It's working! IT'S WORKING!!!"
I want to send a personal "Thank you!" and "God bless you!" to each and every person who has worked tirelessly to bring Logos to Linux. You all have my deepest appreciation. I know things aren't perfect, but it is working and I am over the moon because of it!
For what it's worth, I am on LinuxMint 19.1 "Tessa," Linux kernel 4.15.0-66-generic, on a Dell laptop with AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx × 4.
Also, to get Logos to open initially, I had to switch Wine to Windows 7. After that, it opened and began downloading all my resources perfectly fine and is now indexing my library... though it seems to have hung up around 25 or 27% (in-program is says 25% but the icon in the tray says 27%). But that doesn't bother me much. So long as my resources are there and I can now actually use Logos on Linux, I am ecstatic! [<:o)]
0 -
Anyone else have ClamAV flag just about the entire Logos wine install as malware? Just ran a scan and had over 300 malware hits in the Logos directory
Logos 10 - OpenSuse Tumbleweed, Windows 11, Android 16 & Android 14
0 -
John Goodman said:
I've built debs for 4.18 both architectures and it comes to 191mb. I'll ping them across to you in an email.
Thanks for doing this, it proves that it does compress down to a lot smaller size, which I had been neglecting to consider. I just did a test build with wine bundled and it comes to 442MB, but we were already at something like 383MB, so the bundling of wine is "only" adding about 60MB.
With this growing size, plus the possibility of bundling the Logos.msi installer as well, my newer thought is to split off the various "big files" into multiple .deb packages, like this:
-
wasta-logos-setup: the scripts to get it installed (would be relatively small... maybe a few MB max). It would list as dependencies wasta-wine, wasta-dotnet, and wasta-logos-installer.
-
wasta-wine: bundled wine (32bit only) - again maybe 60-80MB
-
wasta-dotnet: winetricks .NET installers - about 350MB
-
wasta-logos-installer: Logos msi installer - about 185MB
This way users won't need to download a HUGE monolic .deb each time even a minor change occurs. They would only need to download the one that had the changes. The negative is for people not on Ubuntu / .deb based systems they need to manually be taking the files from 4 different packages (or maybe they would be able to be converted using the deb2arch utility or deb2rpm process).
Additionally, there are other .NET apps that we may need to take a similar approach for. By having wasta-dotnet separate, each other package could list it as a depends, following the spirit of .deb packaging. Of course we want to avoid a dependency nightmare so don't want it to get too complicated!
Thoughts with this proposal?
0 -
-
@Rik: Great Idea to split the packages. Future updates only will affect the new packages. Bug-finding will be easier as everyone can start each step by step. I'll try it with my older acer-notebook, where I had no success so far. As soon as the packages are in the repo. Thank you!
Btw. I still hope the enthusiastic posts of so many users will move faithlife to creatve a native soluition for linux. I have this dream...
0 -
Frank Sauer said:
Anyone else have ClamAV flag just about the entire Logos wine install as malware? Just ran a scan and had over 300 malware hits in the Logos directory
I imagine it would because it would expect the windows dlls to have certain fingerprints but since wine is not windows it will look spurious. That's a guess but winehq is a trusted source and so is faithlife.
גַּם־חֹשֶׁךְ֮ לֹֽא־יַחְשִׁ֪יךְ מִ֫מֶּ֥ךָ וְ֭לַיְלָה כַּיּ֣וֹם יָאִ֑יר כַּ֝חֲשֵׁיכָ֗ה כָּאוֹרָֽה
0 -
Rik,
Your idea of breaking up the installer into different parts, many of which do not need to be frequently updated, is an excellent one! Actually, I was going to propose the same thing. That pretty much gets us past the problem of having huge downloads since all of these components will have to be downloaded at least once anyway. If you are able to do this, it will move things much close to a "just works" kind of situation. I think the install process is REALLY improving. If you proceed down this track, we'll get a lot closer to ironing out the install bugs.
Then we can simply turn our attention to functionality and performance bugs.
Thank you so much for your hard work!
Adam
0 -
I have now uploaded version 0.3.0 of wasta-logos-setup. It has as dependencies the following:
-
wasta-wine: patched version of wine 4.18 that will install to /opt/wasta-wine
-
wasta-winetricks: all the .net installers, etc., plus winetricks itself that will install to /opt/wasta-winetricks
It also has as a "recommends":
-
wasta-logos-installer: the Logos-x86.msi that will install to /opt/wasta-logos-installer.
The reason it is a "recommends" is because a user can put a Logos-x86.msi in their ~/Downloads folder if they have their own installer and want to use it instead. If the installer isn't found in ~/Downloads/Logos-x86.msi then it looks for /opt/wasta-logos-installer/Logos-x86.msi. If that also isn't found, then an error is thrown (I took out the logic for the installer to do the download: it was a bit complicated and I think at this point unnecessary).
Since we are now using our own version of wine, there may be some missing 386 library pieces that are needed for full functionality. IF you find errors such as this:
00fa:err:module:load_so_dll failed to load .so lib "/opt/wasta-wine/bin/../lib/wine/winepulse.drv.so": libpulse.so.0: cannot open shared object file: No such file or directory
It most likely means that a needed library is missing, and we need to track it down and add as a dependency of wasta-wine to make sure others get it. Note that in the above example, the solution was to install libpulse0:i386 so that has been added to wasta-wine as a dependency.
If users of distros other than Ubuntu have trouble with some dependencies and can't get wasta-wine installed, then you can manually build (a patched) wine to /opt/wasta-wine and then wasta-logos-setup would be happy (but you will need to remove wasta-wine as a dependency from wasta-logos-setup also). Let us know how non-Ubuntu users get along.
Also due to the size I have limited the Ubuntu builds to 18.04 and 19.10 right now. I am assuming most 19.04 users will be upgrading pretty soon (if not already) to 19.10.
0 -
-
I have just posted version 0.3.0 of wasta-logos-setup. It is a pretty big change in that various bits have been moved to other packages as previously discussed. So please test and report back, but note that it may introduce some bugs. Since it now uses our own patched version of wine, it does NOT assume any wine version is installed on your system. So there should be no conflicts with differing versions of wine for different distros, etc.
Here is a summary of the packages as they stand now:
-
wasta-wine: patched 32-bit version of wine 4.18 that will install to /opt/wasta-wine. NOTE: there may be missing dependencies for some 32bit libraries, so if you get an error like this:
00fa:err:module:load_so_dll failed to load .so lib "/opt/wasta-wine/bin/../lib/wine/winepulse.drv.so": libpulse.so.0: cannot open shared object file: No such file or directory
Then it means a library is missing. Please report the error so we can add the dependency. In the above example, the solution is to install libpulse0:i386 which is now included as a dependency for wasta-wine
-
wasta-winetricks: bundled .NET and other winetricks items that will install to /opt/wasta-winetricks
-
wasta-logos-installer: bundled Logos-x86.msi that will install to /opt/wasta-logos-installer.
-
wasta-logos-setup: small size, has a "depends" wasta-wine and wasta-winetricks. Has as "recommends" wasta-logos-installer, which means it will be installed unless you install like this "sudo apt install --no-install-recommends wasta-logos-setup". The reason a user may NOT want wasta-logos-installer is because if they have a newer installer then wasta-logos-setup will FIRST look in ~/Downloads for Logos-x86.msi. If not found there, then it looks for the wasta-logos-installer version, and if that also isn't found, it returns an error.
Users of other distros besides Ubuntu-based distros may possibly have trouble with the wasta-wine dependencies since the package names may differ per distro. So if this is true, you can manually install a "patched" version of wine to /opt/wasta-wine and then remove the dependency of wasta-wine from wasta-logos-setup. Then hopefully you can get it installed. Let us know how it works if you are on a non-Ubuntu based distro.
Again there may be some missing 32-bit libraries so let me know if the experience of using this 0.3.0 version gives any regressions compared to previous version of wasta-logos-setup. Going forward it should be more stable since we don't have to worry about wine versions changing and breaking the ability to run Logos.
0 -
-
I have just posted version 0.3.0 of wasta-logos-setup. It is a pretty big change in that various bits have been moved to other packages as previously discussed. So please test and report back, but note that it may introduce some bugs. Since it now uses our own patched version of wine, it does NOT assume any wine version is installed on your system. So there should be no conflicts with differing versions of wine for different distros, etc.
Here is a summary of the packages as they stand now:- wasta-wine: patched 32-bit version of wine 4.18 that will install to /opt/wasta-wine. NOTE: there may be missing dependencies for some 32bit libraries, so if you get an error like this:
00fa:err:module:load_so_dll failed to load .so lib "/opt/wasta-wine/bin/../lib/wine/winepulse.drv.so": libpulse.so.0: cannot open shared object file: No such file or directory
Then it means a library is missing. Please report the error so we can add the dependency. In the above example, the solution is to install libpulse0:i386 which is now included as a dependency for wasta-wine-
wasta-winetricks: bundled .NET and other winetricks items that will install to /opt/wasta-winetricks
-
wasta-logos-installer: bundled Logos-x86.msi that will install to /opt/wasta-logos-installer.
-
wasta-logos-setup: small size, has a "depends" wasta-wine and wasta-winetricks. Has as "recommends" wasta-logos-installer, which means it will be installed unless you install like this "sudo apt install --no-install-recommends wasta-logos-setup". The reason a user may NOT want wasta-logos-installer is because if they have a newer installer then wasta-logos-setup will FIRST look in ~/Downloads for Logos-x86.msi. If not found there, then it looks for the wasta-logos-installer version, and if that also isn't found, it returns an error.
Users of other distros besides Ubuntu-based distros may possibly have trouble with the wasta-wine dependencies since the package names may differ per distro. So if this is true, you can manually install a "patched" version of wine to /opt/wasta-wine and then remove the dependency of wasta-wine from wasta-logos-setup. Then hopefully you can get it installed. Let us know how it works if you are on a non-Ubuntu based distro.
Again there may be some missing 32-bit libraries so let me know if the experience of using this 0.3.0 version gives any regressions compared to previous version of wasta-logos-setup. Going forward it should be more stable since we don't have to worry about wine versions changing and breaking the ability to run Logos.0 -
The following messages when running wasta-logos-setup version (0.3.0~ubuntu18.04.1):
user@user:~$ wasta-logos-setup
Gtk-Message: 17:32:47.910: GtkDialog mapped without a transient parent. This is discouraged.
Gtk-Message: 17:32:52.094: GtkDialog mapped without a transient parent. This is discouraged.
sending incremental file list
sent 673 bytes received 19 bytes 1,384.00 bytes/sec
total size is 383,813,768 speedup is 554,644.17
Watching zenity process. If it is canceled then kill PID_PROCESS: 14620
wine: failed to initialize: /opt/wasta-wine/lib/wine/ntdll.dll.so: cannot open shared object file: No such file or directory0 -
How would this impact a user who has already installed Logos? I remember seeing something about updates potentially breaking the install. Would this mean if the install is ever broken, that we would have to redo everything including downloading our entire libraries again? Or is there a way to just update the wine install with this package to prevent the issue going forward - without losing our current install and library?
Rik Shaw said:I have just posted version 0.3.0 of wasta-logos-setup. It is a pretty big change in that various bits have been moved to other packages as previously discussed. So please test and report back, but note that it may introduce some bugs. Since it now uses our own patched version of wine, it does NOT assume any wine version is installed on your system. So there should be no conflicts with differing versions of wine for different distros, etc.
Here is a summary of the packages as they stand now:- wasta-wine: patched 32-bit version of wine 4.18 that will install to /opt/wasta-wine. NOTE: there may be missing dependencies for some 32bit libraries, so if you get an error like this:
00fa:err:module:load_so_dll failed to load .so lib "/opt/wasta-wine/bin/../lib/wine/winepulse.drv.so": libpulse.so.0: cannot open shared object file: No such file or directory
Then it means a library is missing. Please report the error so we can add the dependency. In the above example, the solution is to install libpulse0:i386 which is now included as a dependency for wasta-wine-
wasta-winetricks: bundled .NET and other winetricks items that will install to /opt/wasta-winetricks
-
wasta-logos-installer: bundled Logos-x86.msi that will install to /opt/wasta-logos-installer.
-
wasta-logos-setup: small size, has a "depends" wasta-wine and wasta-winetricks. Has as "recommends" wasta-logos-installer, which means it will be installed unless you install like this "sudo apt install --no-install-recommends wasta-logos-setup". The reason a user may NOT want wasta-logos-installer is because if they have a newer installer then wasta-logos-setup will FIRST look in ~/Downloads for Logos-x86.msi. If not found there, then it looks for the wasta-logos-installer version, and if that also isn't found, it returns an error.
Users of other distros besides Ubuntu-based distros may possibly have trouble with the wasta-wine dependencies since the package names may differ per distro. So if this is true, you can manually install a "patched" version of wine to /opt/wasta-wine and then remove the dependency of wasta-wine from wasta-logos-setup. Then hopefully you can get it installed. Let us know how it works if you are on a non-Ubuntu based distro.
Again there may be some missing 32-bit libraries so let me know if the experience of using this 0.3.0 version gives any regressions compared to previous version of wasta-logos-setup. Going forward it should be more stable since we don't have to worry about wine versions changing and breaking the ability to run Logos.Logos 10 - OpenSuse Tumbleweed, Windows 11, Android 16 & Android 14
0 -
Al Graham said:
The following messages when running wasta-logos-setup version (0.3.0~ubuntu18.04.1):
...
wine: failed to initialize: /opt/wasta-wine/lib/wine/ntdll.dll.so: cannot open shared object file: No such file or directoryAl, can you manually check to see if that file (/opt/wasta-wine/lib/wine/ntdll.dll.so) exists on your system? It should be part of wasta-wine. If it is there, then the message is referring to something else that this file needs, so we need to track it down.
Rik
0 -
Running wasta-logos-setup brought following error:
dirk@roterblitz:~$ wasta-logos-setup
Gtk-Message: 08:52:16.563: GtkDialog mapped without a transient parent. This is discouraged.
....
Gtk-Message: 08:52:35.672: GtkDialog mapped without a transient parent. This is discouraged.
wine: failed to initialize: /opt/wasta-wine/lib/wine/ntdll.dll.so: cannot open shared object file: No such file or directory
Watching zenity process. If it is canceled then kill PID_PROCESS:
Fehler: Müll-Option
Aufruf:
ps [Optionen]
Versuchen Sie »ps --Hilfe <Einfach|Liste|Ausgabe|Threads|Verschiedenes|Alle>«
oder »ps --Hilfe <s|l|o|t|m|a>«,
um zusätzliche Hilfe anzuzeigen.
Für weitere Informationen siehe ps(1).
Zenity process and parallel process both ended: success
Watching zenity process. If it is canceled then kill PID_PROCESS: 5954
Gtk-Message: 08:52:38.949: GtkDialog mapped without a transient parent. This is discouraged.
ls: Zugriff auf '/home/dirk/.wine-logos/drive_c' nicht möglich: Datei oder Verzeichnis nicht gefunden
grep: /home/dirk/.wine-logos/*.reg: Datei oder Verzeichnis nicht gefunden
PID TTY STAT TIME COMMAND
Zenity process and parallel process both ended: success
Watching zenity process. If it is canceled then kill PID_PROCESS: 6005
ls: Zugriff auf '/home/dirk/.wine-logos/drive_c' nicht möglich: Datei oder Verzeichnis nicht gefunden
grep: /home/dirk/.wine-logos/*.reg: Datei oder Verzeichnis nicht gefunden
Gtk-Message: 08:52:43.071: GtkDialog mapped without a transient parent. This is discouraged.
PID TTY STAT TIME COMMAND
Zenity process and parallel process both ended: success
ls: Zugriff auf '/home/dirk/.wine-logos/drive_c' nicht möglich: Datei oder Verzeichnis nicht gefunden
grep: /home/dirk/.wine-logos/*.reg: Datei oder Verzeichnis nicht gefunden
------------------------------------------------------
WINEPREFIX INFO:
Drive C:
Registry info:
/home/dirk/.wine-logos/*.reg:
------------------------------------------------------
------------------------------------------------------
/opt/wasta-wine/bin/wine cmd.exe /c echo '%ProgramFiles%' returned empty string, error message "wine: failed to initialize: /opt/wasta-wine/lib/wine/ntdll.dll.so: cannot open shared object file: No such file or directory"
------------------------------------------------------
ls: Zugriff auf '/home/dirk/.wine-logos/drive_c' nicht möglich: Datei oder Verzeichnis nicht gefunden
grep: /home/dirk/.wine-logos/*.reg: Datei oder Verzeichnis nicht gefunden
------------------------------------------------------
WINEPREFIX INFO:
Drive C:
Registry info:
/home/dirk/.wine-logos/*.reg:
------------------------------------------------------
------------------------------------------------------
/opt/wasta-wine/bin/wine cmd.exe /c echo '%ProgramFiles%' returned empty string, error message "wine: failed to initialize: /opt/wasta-wine/lib/wine/ntdll.dll.so: cannot open shared object file: No such file or directory"
------------------------------------------------------Sudo apt update already told me at the end of the process:
N: Das Laden der konfigurierten Datei »main/binary-i386/Packages« wird übersprungen, da das Depot »http://dl.google.com/linux/earth/deb stable InRelease« die Architektur »i386« nicht unterstützt.
I don't know if this is essential for the problem.0 -
The ntdll.dll is not in the directory /opt/wasta-wine/lib/wine. See my screenshot below with additional informations about my system
0 -
Something is a bit strange because the nttdll.dll.so is in the source at github:
https://github.com/wasta-linux/wasta-wine/tree/master/wasta-wine/lib/wine
And also at launchpad, where the package is built:
https://git.launchpad.net/wasta-wine/tree/wasta-wine/lib/wine
So we need to figure out why it isn't in the package (or is maybe getting removed)? Do you have wasta-wine version 0.1.1?
0 -
I used a fresh install of Mint 19.2 without any previous wasta-logos versions. I started directly with the 0.3.0 version following your google-doc.
0
