https://bugs.winehq.org/show_bug.cgi?id=45091
Bug ID: 45091
Summary: wineboot: first boot hangs forever
Product: Wine
Version: 3.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: comeon(a)getbackinthe.kitchen
Distribution: ---
Created attachment 61260
--> https://bugs.winehq.org/attachment.cgi?id=61260
debug output
When I try to boot wine for the first time with no .wine folder, wine just
hangs forever. When doing `winecfg' without a .wine folder, it waits for about
5 minutes before saying:
0009:err:process:__wine_kernel_init boot event wait timed out
and then opening the winecfg menu. Can't see drives with this error:
0015:err:winecfg:open_mountmgr failed to open mount manager err 2
Attached the gzipped output of `WINEDEBUG=warn+all,err+all,fixme+all wineboot
-i', with no .wine folder.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44403
Bug ID: 44403
Summary: On macOS during first run, Wine configuration
population hangs
Product: Wine
Version: 3.0
Hardware: x86
OS: Mac OS X
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: joe.abbey(a)docker.com
Wine 3.0 is installed using brew for a CI job using electron-loader to build an
installer.
The first time wine runs, it creates the ~/.wine directory and registries.
Wine never completes, and hangs. Force killing the wine dialog and wine64
process produces enough configuration for a second run to complete.
Force killing during CI seems like a bad way forward.
To reproduce
rm -rf ~/.wine
brew install wine
Run any wine application and it will hang on config generation.
This is currently breaking Kitematic builds.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56515
Bug ID: 56515
Summary: Calling "wine reg ..." from python's subprocess lead
UnicodeDecodeError if locale isn't us_EN.UTF-8.
Product: Wine
Version: 9.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: alandms123(a)gmail.com
Distribution: ---
Created attachment 76271
--> https://bugs.winehq.org/attachment.cgi?id=76271
Python script as an example.
Before concluding this I tested running other programs using Python's
subprocess tools, "rm --help", "ls --help", "man --help", etc. All of them have
it's output displayed normally in the language set by locale LANG environment
variable, every non-English character gets decoded in utf-8 normally.
But here it's what happens when trying run wine reg while scripting in python:
Traceback (most recent call last):
File "call_wine_reg_script.py", line 31, in <module>
out, err = res.communicate()
^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/subprocess.py", line 1196, in communicate
stdout = self.stdout.read()
^^^^^^^^^^^^^^^^^^
File "<frozen codecs>", line 322, in decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc6 in position 6: invalid
continuation byte
This happens because my system locale is set to use "pt_BR.UTF-8" and Wine's
output is trying to output the word "Não" the "ã" gets interpreted as 0xc6 "Æ"
latin-1 as utf-8 which end up in a UnicodeDecodeError.
I attached the script (anyone testing will have to change the prefix path). I
tried setting locale on the script, tried passing the environment variables to
the Popen command, but the outcome is always the same.
In the example script I used ja_JP.UTF-8, but any language that has non-English
character will have the same problem.
I tested with other Wine's commands like wineboot, winecfg, etc, but all of
them displays English text so no problem there, if there's any other Wine's
command that change it's output language based on the LANG environment
variable, I think it will trigger it.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.