wine-bugs September 2019

wine-bugs@winehq.org

1 participants
7655 discussions

[Bug 13273] New: Wine does not remember disk labels set through winecfg
by wine-bugs＠winehq.org 12 Nov '19

12 Nov '19

http://bugs.winehq.org/show_bug.cgi?id=13273 Summary: Wine does not remember disk labels set through winecfg Product: Wine Version: 1.0-rc1 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: ccf2egd02(a)sneakemail.com Wine does not seem to remember disk labels or serial numbers when set via winecfg. Steps to reproduce: 1) create a disk entry in ~/.wine/dosdevices ln -s /someplace_with_CD_image ~/.wine/dosdevices/q\: 2) run winecfg, select disk tab. 3) Select q: 4) Show advanced 5) Set to manual setup, disk label to "SOMETHING", disk ID to "FEEDBE" 6) APPLY 7) verify data by selecting some other drive, then re-selecting q: 8) quit winecfg 9) Restart winecfg and reselect the disk tab. Reselect q: Expected results Disk label should be "SOMETHING", id should be "FEEDBE" Actual results Disk label unset, disk ID 0 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 24

[Bug 38933] New: In LiveCode 5.0.2, modal dialog prompts are created behind all windows, hanging Wine.
by wine-bugs＠winehq.org 11 Nov '19

11 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=38933 Bug ID: 38933 Summary: In LiveCode 5.0.2, modal dialog prompts are created behind all windows, hanging Wine. Product: Wine Version: 1.7.47 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexchandel(a)gmail.com In LiveCode 5.0.2, whenever a dialog prompt is created, wine creates the modal window behind the main window. Since the application is blocked until the modal window is acknowledged, there is no way to continue, and LiveCode is effectively hung. Note this does not apply to system prompts, such as the file chooser; only popups containing custom text, often created with a LiveCode script such as `ask "foo bar"`, which when run immediately hangs Wine, since a dialog window is created behind a much larger primary window (assuming one exists). This error actually effects all LiveCode windows, but it is only critical for dialogue windows, since those halt the program. This *may* be related to 16346, although that was documented on X11, not Aqua. -- 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.

2 6

[Bug 16346] New: App hangs creating modal dialog from WM_ACTIVATEAPP
by wine-bugs＠winehq.org 11 Nov '19

11 Nov '19

http://bugs.winehq.org/show_bug.cgi?id=16346 Summary: App hangs creating modal dialog from WM_ACTIVATEAPP Product: Wine Version: 1.1.10 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: major Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: jmiller-wine(a)tanner.com CC: jmiller-wine(a)tanner.com Created an attachment (id=17660) --> (http://bugs.winehq.org/attachment.cgi?id=17660) Simple windows app with source that brings up a message box every time the window is activated. I have an app which opens a modal dialog under some circumstances when the window is activated. Under Windows this works perfectly, but under wine it causes the app to hang. I have attached a trivial sample app showing this behavior. I poked around a bit, and the app is no longer receiving any messages (mouse moves, keyboard, paint, etc), but I'm not sure where to go from here. Also under Windows, since the app checks for the wParam (bActive) on WM_ACTIVATEAPP, it only brings up one copy of the dialog box even after multiple window activations. Under wine it will bring up another copy of the dialog if there is already a modal dialog on that app. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 23

[Bug 46001] New: MANY com.apple.xbs/Sources/ AppleFSCompression errors from every wine process
by wine-bugs＠winehq.org 11 Nov '19

11 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=46001 Bug ID: 46001 Summary: MANY com.apple.xbs/Sources/AppleFSCompression errors from every wine process Product: Wine Version: 3.18 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexchandel(a)gmail.com Distribution: --- Every wine process I run prints the following error message at some point: /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.200.3/Common/ChunkCompression.cpp:49: Error: unsupported compressor 8 /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.200.3/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist' /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.200.3/Common/ChunkCompression.cpp:49: Error: unsupported compressor 8 /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.200.3/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist' The simplest replication is just running `winecfg` with a new wine prefix. I'm using macOS 10.14, but this has happened since at least 10.13. I've never seen it from any non-wine program ever. -- 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.

2 4

[Bug 46002] New: "0011:err:display: macdrv_ChangeDisplaySettingsEx No matching mode found 1680x1050x32 @60!" every time wine starts
by wine-bugs＠winehq.org 11 Nov '19

11 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=46002 Bug ID: 46002 Summary: "0011:err:display:macdrv_ChangeDisplaySettingsEx No matching mode found 1680x1050x32 @60!" every time wine starts Product: Wine Version: 3.18 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexchandel(a)gmail.com Distribution: --- Every single time wine starts, it displays the error message 0011:err:display:macdrv_ChangeDisplaySettingsEx No matching mode found 1680x1050x32 @60! at some point. 1680x1050 is indeed the effective resolution of the display, though the actual resolution is 2560x1600. What error is happening? -- 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.

2 3

[Bug 24945] New: font is not drawn in synth1 instrument selection window
by wine-bugs＠winehq.org 10 Nov '19

10 Nov '19

http://bugs.winehq.org/show_bug.cgi?id=24945 Summary: font is not drawn in synth1 instrument selection window Product: Wine Version: 1.3.4 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: fonts AssignedTo: wine-bugs(a)winehq.org ReportedBy: armandsl(a)gmail.com Created an attachment (id=31583) --> (http://bugs.winehq.org/attachment.cgi?id=31583) synth1 on wine 1.3.4 Starting with wine version 1.2.0 font is not drawn in synth1 instrument selection window anymore. Synth1 is free VST software synthesizer (http://www.geocities.jp/daichi1969/softsynth/). OS used: Linux (Fedora 14) Dll is loaded by LMMS (Linux Multi Media System) version 0.4.8 It worked with wine 1.1.38 (with old font subsystem). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 20

[Bug 46517] New: Warcraft III: Installation fails ( trouble launching Battle.net Update Agent)
by wine-bugs＠winehq.org 09 Nov '19

09 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=46517 Bug ID: 46517 Summary: Warcraft III: Installation fails (trouble launching Battle.net Update Agent) Product: Wine Version: 4.0-rc7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: winehq(a)iooioio.hadar.uberspace.de Distribution: Ubuntu Created attachment 63372 --> https://bugs.winehq.org/attachment.cgi?id=63372 Console output I am currently unable to install Warcraft III via the installer provided by Blizzard. It's a web installer (used to work in the past) so the problem might be related to wine network code. Attached you will find the console output and a screenshot of the error message in the application. -- Some additional info about my system (just in case): Distro: elementary OS Juno Kernel: 4.15.0-43-generic Graphics: Proprietary NVIDIA 410.78 -- 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.

2 3

[Bug 38521] New: Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x7
by wine-bugs＠winehq.org 09 Nov '19

09 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=38521 Bug ID: 38521 Summary: Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x7 Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: ettl.martin78(a)gmail.com Distribution: --- Created attachment 51390 --> https://bugs.winehq.org/attachment.cgi?id=51390 backtrace from wine Steps to reproduce: 1) Install SourceNavigator from (http://sourceforge.net/projects/sourcenav/?source=typ_redirect) on Ubuntu Linux 15.04 (32-Bit) with wine. 2) Execute SourceNaviator 3) Close SourceNaviator 4) The exception message is shown. Please refer to the backtrace. If you have questions, please feel free to ask. Many thanks for working so hard on wine. Best regards Martin Ettl -- 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.

2 8

[Bug 39709] New: winmm:mci makes a buzzing sound
by wine-bugs＠winehq.org 07 Nov '19

07 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=39709 Bug ID: 39709 Summary: winmm:mci makes a buzzing sound Product: Wine Version: 1.8-rc2 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: winmm&mci Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Running winmm:mci makes a buzzing sound. The first line (of many) where this happens is the line below from test_playWAVE(): /* A second play caused Wine<1.1.33 to hang */ err = mciSendStringA("play mysound from 500 to 220:5:0 wait", NULL, 0, NULL); This is because the test records sound to tempfile.wav before playing it back. So if the recording levels are set a bit high tempfile.wav can record electrical noise, the buzzing sound, and thus makes noise when playing it back. This is confirmed by changing the recording level in the KDE mixer prior to running the test: * Setting it all the way down avoids the buzzing sound. * Setting it even moderately high causes the buzzing sound. Conformance tests are supposed to not make noises when not run in interactive mode so this should be fixed. I see two ways for this: * Set and restore the recording level in test_recordWAVE(). * Create tempfile.wav by hand instead of relying on the output of test_recordWAVE(). -- 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.

2 1

[Bug 47855] New: Run tests in more than one VM at a time
by WineHQ Bugzilla 07 Nov '19

07 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=47855 Bug ID: 47855 Summary: Run tests in more than one VM at a time Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Some Wine tests have pretty stringent timing requirements: * Some audio tests play a short sound bite and make sure the playback lasted for the expected time within a few tens of seconds as a way to ensure audio is played at the right rate. But VMs are not always very good at respecting precise timing requirements when there is other activity on the host. * Some tests (msi) generate quite a bit of disk traffic and take a while to run. Running two of those simultaneously can sometimes push them over the 2 minutes limit, causing them to time out. That said there may be something else afoot here as these run times vary from ~20s to ~100s depending on the VM for seemingly no reason. As a consequence the TestBot is configured to only do one thing at a time: run at most one test or revert one VM. This is at odds with hardware evolution and new TestBot requirements: * SSDs are much faster than hard drives and thus should solve the disk bottleneck issues. * The builds for the Wine VMs take a lot more time than just producing PE executables for the Windows VMs. To speed up compilation it is necessary to increase the parallelism which means buying a machine with as many cores as possible and assigning as many as possible to the Wine VMs. * But while running single threaded tests in a single VM on a quad-core machine is bad enough, doing the same thing on a 16+ threads machine would truly be a waste. So a way to be able to run tests in more than one VM at a time should be found. The first step would be to verify that these issues still exist (this means distinguishing them from the usual random failures). If they don't then problem solved! Otherwise CPU-pinning is a solution that's usually mentioned in gaming circles. The questions are: * Would it actually help? * How to integrate it with the TestBot. Is this something that should be configured through Libvirt when restoring a live snapshot? Or is this something that should be defined 'statically' in the VM's configuration? * What happens if two VMs are pinned to the same CPU core? Will Libvirt prevent us from starting both at the same time or is it up to the TestBot Engine to make sure this does not happen? How? * What happens when a VM that's is pinned to CPU core 7 is moved to a 4 core host? Is the pinning ignored or does the administrator have to manually change its configuration? -- 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.

1 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs September 2019