wine-bugs December 2019

wine-bugs@winehq.org

1 participants
7451 discussions

[Bug 47759] New: Origin - Not possible to sign on or go online
by WineHQ Bugzilla 12 Dec '19

12 Dec '19

https://bugs.winehq.org/show_bug.cgi?id=47759 Bug ID: 47759 Summary: Origin - Not possible to sign on or go online Product: Wine Version: 4.15 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: maiktapwagner(a)aol.com Distribution: --- Created attachment 65241 --> https://bugs.winehq.org/attachment.cgi?id=65241 Console output - wine 4.15 (staging) Hello everyone, After starting "Origin" I keep getting a message that it is aparently not possible to sign in online. I also tried signing in in offline mode (which works) and tried "Go online" in the main menu. This also fails. Anyway, console output for latest wine staging is attached. -- 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 10

[Bug 37567] New: Skype home page is totally blank
by wine-bugs＠winehq.org 12 Dec '19

12 Dec '19

https://bugs.winehq.org/show_bug.cgi?id=37567 Bug ID: 37567 Summary: Skype home page is totally blank Product: Wine Version: 1.7.31 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mshtml Assignee: wine-bugs(a)winehq.org Reporter: t.artem(a)mailcity.com Distribution: Red Hat Make sure you deleted login.cab before trying to debug this issue (proper HTML support is not yet there, see bug 28457). Skype version: 6.21.32.104 -- 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 7

[Bug 48238] New: wrong display minimized windows
by WineHQ Bugzilla 12 Dec '19

12 Dec '19

https://bugs.winehq.org/show_bug.cgi?id=48238 Bug ID: 48238 Summary: wrong display minimized windows Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: disinbox(a)gmail.com Distribution: --- Icons of minimized windows are not displayed. Window titles displayed instead (which is wrong, it is no need in displaying titles for this windows) This wrong minimized windows display behaivior affect Quik financial application since wine-4.3 (wine-4.2 and earlier was correct) Bisecting with git i have found two wrong commits: commit added unneded title bars: commit 3765b3307e772abf2430fe8e975ec5e72fc3d1f1 Author: Zebediah Figura <z.figura12(a)gmail.com> Date: Tue Feb 19 12:17:42 2019 -0600 user32: Paint title bars for minimized windows. Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> dlls/user32/nonclient.c | 34 ++++++++++------------------------ 1 file changed, 10 insertions(+), 24 deletions(-) commit erased background of icons of minimized windows: commit ed0eaecf178a811a83b70c79891a98eedcfe0291 Author: Zebediah Figura <z.figura12(a)gmail.com> Date: Tue Feb 19 12:17:37 2019 -0600 user32: Correctly calculate the client size of a minimized window. Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> -- 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 5

[Bug 47877] New: Allow enabling Gallium Nine in official wine-staging builds
by WineHQ Bugzilla 12 Dec '19

12 Dec '19

https://bugs.winehq.org/show_bug.cgi?id=47877 Bug ID: 47877 Summary: Allow enabling Gallium Nine in official wine-staging builds Product: Wine-staging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: kolan_n(a)mail.ru CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Wine should detect if Gallium Nine is present, and if it is, a checkbox activating its usage in winecfg should be enabled. If I guess right (I have not checked the source, but the fact that unofficial builds have this checkbox but the official ones don't suggests that it is a compile-time option) currently official wine-staging builds don't use nine. -- 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

[Bug 40801] New: DAoC: Software vertex blending crash
by wine-bugs＠winehq.org 12 Dec '19

12 Dec '19

https://bugs.winehq.org/show_bug.cgi?id=40801 Bug ID: 40801 Summary: DAoC: Software vertex blending crash Product: Wine Version: 1.9.12 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3dx9 Assignee: wine-bugs(a)winehq.org Reporter: hpj(a)copyleft.no Distribution: --- Created attachment 54728 --> https://bugs.winehq.org/attachment.cgi?id=54728 wine-1.9.12-daoc-sw-vertex-blending.patch Out of nostalgia I decided to try to fire up Dark Age of Camelot, which I played under Cedega at one point in the 00s. I followed the instructions at https://appdb.winehq.org/objectManager.php?sClass=version&iId=9368 sans the patch, and it crashed at the character selection screen, as expected. The linked-to patch no longer applies to Wine master (1.9.12+), and the latest patch in bug 39057 didn't improve the situation either. I rebased the patch from the appdb entry (bug 6955) onto git master, after which the game seemed to run perfectly. -- 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 22

[Bug 47218] New: "--rpath" given via LDFLAGS is not honored as wine precedes a "--rpath,$ORIGIN"
by wine-bugs＠winehq.org 12 Dec '19

12 Dec '19

https://bugs.winehq.org/show_bug.cgi?id=47218 Bug ID: 47218 Summary: "--rpath" given via LDFLAGS is not honored as wine precedes a "--rpath,$ORIGIN" Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: build-env Assignee: wine-bugs(a)winehq.org Reporter: mail+wine(a)m-reimer.de Distribution: --- I've tried to do a proper fix but gave up after some time. I want to build wine against a patched glibc to work around https://bugs.winehq.org/show_bug.cgi?id=47198 I thought it should be enough to pass "-Wl,--rpath" via LDFLAGS but this doesn't work as the LDFLAGS are appended *after* Wine adds a "-Wl,--rpath,$ORIGIN". As rpath's are applied in command line order, my "rpath" isn't applied. This, for example, happens when "wine64-installed" is built. My crude fix is: _RPATH="-rpath=/usr/wine-lol-glibc/lib,-rpath=/usr/wine-lol-glibc/lib32" export LDFLAGS="$LDFLAGS,$_RPATH" sed "s|-Wl,--rpath,|-Wl,$_RPATH,--rpath,|g" -i $pkgname/configure* Can you fix this order, so your own "rpath" settings is applied *after* supplied LDFLAGS are added? -- 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 2

[Bug 41093] New: Darkfall New Dawn doesn't recognize game data
by wine-bugs＠winehq.org 12 Dec '19

12 Dec '19

https://bugs.winehq.org/show_bug.cgi?id=41093 Bug ID: 41093 Summary: Darkfall New Dawn doesn't recognize game data Product: Wine Version: 1.9.14 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: joelpartanen(a)tutanota.com Distribution: --- Created attachment 55297 --> https://bugs.winehq.org/attachment.cgi?id=55297 3 console logs: fresh install, wininet installed and wininet installed with rasapi32 set to native I've been attempting to get Darkfall: New Dawn for a couple of days now. Currently, the program cannot me installed on wine, so I have installed and patched the game on a Windows virtual machine and then transferred it to a fresh wine prefix. I have added the correct Windows registry entries. They are (both string/value pairs): [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Ub3rgames\Darkfall New Dawn] DataPath = C:\Program Files\Darkfall New Dawn\data\ ProgramPath = C:\Program Files\Darkfall New Dawn\ On a Windows machine, if I don't run the installer of the program but instead simply add the said registry entries, the game runs, provided the paths are set correctly (I can also move the program to another folder, update the paths and it will work). On wine, this will not work. A way to test if the game recognises the installation seems to be to attempt to run 'darkfall.exe' in the data directory directly. On Windows, if the registry entries are not said, this will spawn an error saying the game is not installed correctly. This same error however always appear on wine, no matter if the registry keys are set or not. Since I am no wine expert, I have also been pondering if the problem could be internet access. After installing wininet via winetricks, console output at time of running the game changes, and I noticed the following line: fixme:ras:RasEnumConnectionsW RAS support is not implemented! Configure program to use LAN connection/winsock instead! So in addition to a fresh install with the bare minimum of libraries installed, I also attempted with wininet installed, and lastly, due to the RasEnumConnectionsW error, I tried setting rasapi32 to 'native' in winecfg. Console outputs for all of these are included in the attached file. I also tried to install the game in wine 1.7.4 and received similar results, so I don't believe this to be a regression issue. Lastly, the wineprefixes I've tried have been 32-bit - I also tried a 64-bit one, but there the launcher itself crashes when opened. The wine version used is indeed the official 1.9.14. Should somebody need the program to debug the issue, it is freely available upon registration on it's website. -- 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 5

[Bug 47245] New: PVproctor: Hangs halfway through install.
by wine-bugs＠winehq.org 12 Dec '19

12 Dec '19

https://bugs.winehq.org/show_bug.cgi?id=47245 Bug ID: 47245 Summary: PVproctor: Hangs halfway through install. Product: Wine Version: 4.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: linux(a)klomp.ca Distribution: --- The installation starts with asking some questions and accepting the licensing info. Then at the halfway point of the install progress bar, nothing further happens. It just hangs. Some fixme errors point to audio issues, but not sure how to fix those. See https://pastebin.com/27Uywffz The program was downloaded from: http://download-us-east-1.proctorcam.com/production/pearson_vue/PVproctor-2… My system : Ubuntu 16.04.6 LTS -- 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 48040] New: Allow running more than one VM per host
by WineHQ Bugzilla 12 Dec '19

12 Dec '19

https://bugs.winehq.org/show_bug.cgi?id=48040 Bug ID: 48040 Summary: Allow running more than one VM per host 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: --- The TestBot VM hosts have 4 to 8 cores. Wine's tests are essentially single threaded, typically remain far from maxing out even a single core, and don't have that much I/O requirements except for the msi tests. But a number of tests are timing sensitive (audio tests) in that a delay of a fraction of a second can make them fail. It was found a long time ago that running two or more WineTest instances in separate VMs concurrently would cause extra test failures. The reason for these failures was either timeouts in the msi tests (so slow I/O) or timing related in the audio tests. But then there are even more random test failures at the time, making assessment tricky. So while the TestBot can run an arbitrary number of concurrent VMs per host, its current configuration limits it to just one VM at a time. There are a number of evolutions that make this situation less and less tenable: * We have more and more Windows configurations to test, whether that's because of new Windows releases, or new configurations such as dual-screen, locales, etc. * Tests on Wine involve longer rebuilds that just building the Windows test executables and would benefit greatly from more cores. * Future hosts are more likely to get 8, 12 or 16 core CPUs (+hyperthreading) with SSDs. With the current limit scaling up means adding more underutilized VM hosts. So this limit should be reevaluated and was way to lift it found if there are still issues. * Find a way to reliably assess whether one configuration provides worse results than another despite the possible presence of random failures. * At the time qcow2 disk I/O seemed to have a global lock issue which may have been responsible for some of the poor I/O performance and scheduling delays. -> Check whether that's still the case and if there are workarounds. * There are two I/O models: native and threaded. -> Check if one configuration is better than the other with regards to scheduling issues and interference across VMs. * Some gamers report that vcpu pinning can reduce latency variations. Also tweaking the vcpu topology is said to help sometimes. -> This sounds like something that would be beneficial for our audio tests so investigate it. Should the pinning be done statically or set by the TestBot before starting up the VM based on the set of already running VMs. In the case of a static allocation, how should the exclusion patterns be communicated to the TestBot? https://mathiashueber.com/cpu-pinning-on-amd-ryzen/ https://www.reddit.com/r/VFIO/comments/7zcn5g/kvm_windows_10_guest_cpu_pinn… -- 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 2

[Bug 32930] New: Age of wonders 2 and to a lesser extent Age of wonders shadow magic suffer from mouse lag when on direct3d
by wine-bugs＠winehq.org 12 Dec '19

12 Dec '19

http://bugs.winehq.org/show_bug.cgi?id=32930 Bug #: 32930 Summary: Age of wonders 2 and to a lesser extent Age of wonders shadow magic suffer from mouse lag when on direct3d Product: Wine Version: unspecified Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: i30817(a)gmail.com Classification: Unclassified I may be overreaching with the conclusions but it seems that a well known design problem of Direct3d/windows device api made the jump to wine, even though a normal workaround in windows is to 'use opengl'. These games suffer from what is commonly called 'floating cursor' or mouse lag if configured with direct3d (supposedly the hardware mode and the most efficient). If you search for 'direct3d mouse lag' you come across numerous blogs/forums explaining the cause. http://my.opera.com/Vorlath/blog/2009/02/01/directx-d3d-mouse-lag http://www.southwindsgames.com/blog/2009/01/15/mouse-lag-keyboard-lag-direc… http://forums.indiegamer.com/showthread.php?15469-Mouse-Lag-with-D3D So this is a bit of a problem for those games and probably more. Even a wine registry hack would be nice -- 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 14

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 December 2019