wine-bugs June 2021

wine-bugs@winehq.org

1 participants
5070 discussions

[Bug 38409] New: Wine Task Tray does is not in the taskbar KDE 5
by wine-bugs＠winehq.org 09 Oct '22

09 Oct '22

https://bugs.winehq.org/show_bug.cgi?id=38409 Bug ID: 38409 Summary: Wine Task Tray does is not in the taskbar KDE 5 Product: Wine Version: 1.7.40 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jack(a)emoss.org Distribution: --- The wine System Tray is not linked to the KDE desktop at all in KDE 5 but it worked fine in KDE 4. -- 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 99

[Bug 45364] New: Frostpunk
by wine-bugs＠winehq.org 08 Oct '22

08 Oct '22

https://bugs.winehq.org/show_bug.cgi?id=45364 Bug ID: 45364 Summary: Frostpunk Product: Wine Version: 3.10 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hewanci(a)gmail.com Distribution: --- Frostpunk is so dark that it's unplayable due to not being able to see what's happening. Steam version Staging 3.10 Arch Linux There is already a bug about glitches but I doN't know how related that is: bug 45098 -- 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 11

[Bug 17638] New: NOLF GotY: Sluggish mouse reaction when in zoom mode
by wine-bugs＠winehq.org 08 Oct '22

08 Oct '22

http://bugs.winehq.org/show_bug.cgi?id=17638 Summary: NOLF GotY: Sluggish mouse reaction when in zoom mode Product: Wine Version: 1.1.16 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: liquid.acid(a)gmx.net CC: jb.faq(a)gmx.de Mouse input in NOLF is generally a bit "inprecise", but one thing is broken for sure. Some weapons feature a zoom mode, but when this zoom mode is switched on it's almost impossible to accurately use it since the mouse input becomes very sluggish then. Turn zoom off again and mouse input stabilizes again. I suppose that's a dinput problem, but I'm not sure about that. The wine-0.9.46 testresult here (http://appdb.winehq.org/objectManager.php?sClass=version&iId=305&iTestingId…) mentions a "weird mouse problem", but I'm not sure if that's what I'm encountering. Haven't tried any native DLLs though. -- 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 31157] New: Filemaker Pro 12 Trial crashes
by wine-bugs＠winehq.org 07 Oct '22

07 Oct '22

http://bugs.winehq.org/show_bug.cgi?id=31157 Bug #: 31157 Summary: Filemaker Pro 12 Trial crashes Product: Wine Version: 1.2.3 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: maikwagner(a)yahoo.com Classification: Unclassified Created attachment 40903 --> http://bugs.winehq.org/attachment.cgi?id=40903 Crash Output on Filemaker 12 I would like to report some issues with Filemaker 12 Trial which can be downloaded from Filemaker.com. The application installs okay and I can start "Filemaker 12" from the command line. When opening a sample solution (I selected "Invoices") the application crashes. I have attached my console output. -- 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 36

[Bug 30666] New: MPEG movie does not play in Capitalism 2 demo
by wine-bugs＠winehq.org 07 Oct '22

07 Oct '22

http://bugs.winehq.org/show_bug.cgi?id=30666 Bug #: 30666 Summary: MPEG movie does not play in Capitalism 2 demo Product: Wine Version: 1.5.4 Platform: x86 URL: http://www.cnwcentral.com/capitalism-2/demo.shtml OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winegstreamer AssignedTo: wine-bugs(a)winehq.org ReportedBy: jeremielapuree(a)yahoo.fr Classification: Unclassified Created attachment 40144 --> http://bugs.winehq.org/attachment.cgi?id=40144 console output While playing intro movie of Capitalism 2 demo, one can hear the sound, but video is playing. -- 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 11

[Bug 48912] New: Allow blacklisting unreliable and always new failures
by WineHQ Bugzilla 06 Oct '22

06 Oct '22

https://bugs.winehq.org/show_bug.cgi?id=48912 Bug ID: 48912 Summary: Allow blacklisting unreliable and always new failures 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: --- A number of tests produce false positives because: * Either the failure message contains a value that changes with each run (e.g. an HWND). In some cases these values are really necessary for diagnosis and moving them to a separate line would make the code quite a bit more complex. * Or the test fails intermittently and is hard to fix. Sometimes the cause of the failures may also come from external factors such as bugs in QEmu (for instance long execution delays causing timeouts). * Sometimes the intermittent failure is the product of a new Windows version or configuration, which requires investigating before a fix is found. In all cases the tests should be fixed eventually, but a solution is needed for the interim so these tests to not make the TestBot so unreliable that its results are ignored. So the goal is to provide a way to blacklist some test failures so they do not cause a patch to be rejected. Some safeguards are needed to ensure that: * Failures are not blacklisted lightly. The preference should always be to fix the test. * The blacklist does not get so large that it becomes hard to maintain. * Once a test is fixed the corresponding blacklist entries are removed in a timely fashion. * There is still an incentive to fix the tests. So here is a proposal for implementing this blacklist: * Each blacklist entry should be associated with a Wine bug describing the issue. That bug should provide some minimal diagnosis: whether it's a new Windows behavior, a race condition or some issue that was reported to QEmu. That would ensure we know why the blacklist entry was added. One could also check the status of the bug when reviewing the blacklist entries. A closed bug would be a strong hint that the blacklist entry is no longer needed. * Rather than blacklisting whole test units, blacklist entries should target specific test failures via a regular expression. Besides being finer grained this would be useful for cases like user32:win which has different issues depending on the locale and where each should be linked to a different bug (bugs 48815, 48819 and 48820). * The TestBot should record when each blacklist entry was last used. This relies on having the above regular expression since without it the TestBot would not know anything beyond 'the test unit was run and had failures'. Also the regular expression would only be used against *new* failures. So this would really record the last time the blacklist entry was actually useful. An entry that was unused for a long time would be a prime candidate for reviewing the corresponding bug and for removal. (Note: The blacklist would also be used on WineTest reports so it would get a chance of matching its target at least 5 days / week). * The blacklist entries would only be needed for 'base' test configurations since they are the only ones wine-devel patches run on. * There should be a page listing the blacklist entries so developers have a good starting point to work on them. * Ideally the blacklist page would also point to the tasks where the blacklist was last used. Since most of the blacklisted failures are either intermittent or specific to a given test configuration this would make it easier for developers to find reports where the failure did happen. Note that Wine VMs often test multiple configurations per task (e.g. wow32 and wow64, different locales), each producing its own test report. So pointing at just the task would leave the developer guessing which report should be looked at. But that may be sufficient guidance. * (test:unit, testbot-vm) tuples make it impossible to target a specific Wine test configuration such as a specific locale since they all run on the same VM. Similarly it would make blacklisting bitness-blind on Windows VMs. If necessary the tuple could be extended either with the specific mission the blacklist applies to, or with the basename of the corresponding report (the latter being easier to use in comparisons). Whether that's practical and worth the effort remains to be determined. One complication for instance is that this would lead to more blacklist entries: many 64 bit VMs would need two entries, one for 32 bit tests and one for 64 bit tests. * Pseudo database schema and sample use: FailureBlacklists ----------------- PK Bug 48815 PK TestModule user32 PK TestUnit win Name 0x738 message FailureRegExp Test failed: hwnd [0-9A-F]{8,16} message 0738 LastUse 2020-03-27 FailureBlacklistVMs ------------------- PK Bug 48815 PK TestModule user32 PK TestUnit win PK VMName Entries for w1064v1709, w1064v1809, etc. (48815, user32, win, w1064v1709) (48815, user32, win, w1064v1809) (48815, user32, win, w1064v1809_2scr) ... FailureBlacklistUses (optionally) --------------------------------- PK Bug PK TestModule PK TestUnit PK JobId PK StepNo PK TaskNo (48815, user32, win, 68507, 1, 7) (48815, user32, win, 68508, 1, 7) ... -- 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 48209] New: Ignore random parts of test failure messages
by WineHQ Bugzilla 06 Oct '22

06 Oct '22

https://bugs.winehq.org/show_bug.cgi?id=48209 Bug ID: 48209 Summary: Ignore random parts of test failure messages 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 needs to detect if a patch introduces NEW test failures. To do so it compares the failure messages with those from reference WineTest runs. But in some cases part of the message changes from one run to the next, causing the failure to look new. Of course in all cases the ideal solution is to fix the test so it does not fail. Barring that there are also cases where the varying value is not really useful (e.g. handle or pointer values) and in that case it should just be removed from the message. But there may be cases where knowing the value is still useful. So one solution would be to tag such values so the TestBot knows it can ignore them when comparing failure messages. For instance they could be enclosed in double braces, curly braces, or other. -- 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 36103] New: kernel32/tests/loader shows lots of invalid reads in thread.c
by wine-bugs＠winehq.org 01 Oct '22

01 Oct '22

https://bugs.winehq.org/show_bug.cgi?id=36103 Bug ID: 36103 Summary: kernel32/tests/loader shows lots of invalid reads in thread.c Product: Wine Version: 1.7.17 Hardware: x86 OS: Linux Status: NEW Keywords: download, testcase Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com ==9219== Invalid read of size 4 ==9219== at 0x7BC55D91: MODULE_DllThreadAttach (loader.c:1287) ==9219== by 0x7BC8E3D2: start_thread (thread.c:423) ==9219== by 0x4218F92: start_thread (pthread_create.c:309) ==9219== by 0x431D7ED: clone (clone.S:129) ==9219== Address 0x611eb04 is on thread 1's stack ==9219== ==9219== Invalid read of size 4 ==9219== at 0x7BC1EAF3: __x86.get_pc_thunk.bx (in /home/austin/wine-valgrind/dlls/ntdll/ntdll.dll.so) ==9219== by 0x7BC8E3D2: start_thread (thread.c:423) ==9219== by 0x4218F92: start_thread (pthread_create.c:309) ==9219== by 0x431D7ED: clone (clone.S:129) ==9219== Address 0x611eacc is on thread 1's stack ==9219== there's also one: ==30099== 2,020 bytes in 1 blocks are possibly lost in loss record 225 of 244 ==30099== at 0x7BC4C735: notify_alloc (heap.c:255) ==30099== by 0x7BC50F79: RtlAllocateHeap (heap.c:1716) ==30099== by 0x4E07A19: get_tls_data (test.h:244) ==30099== by 0x4E07B03: winetest_set_location (test.h:279) ==30099== by 0x4D836B8: dll_entry_point (loader.c:1433) ==30099== by 0x7BC52FC0: ??? (loader.c:138) ==30099== by 0x7BC555FE: MODULE_InitDLL (loader.c:1068) ==30099== by 0x7BC55DE7: MODULE_DllThreadAttach (loader.c:1281) ==30099== by 0x7BC8E446: start_thread (thread.c:423) ==30099== by 0x4EA7BD89: start_thread (in /usr/lib/libpthread-2.18.so) ==30099== by 0x4E95CA0D: clone (in /usr/lib/libc-2.18.so) ==30099== -- 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 48468] New: Add "Bronze" and "Garbage" top-10 lists to the appdb landing page
by WineHQ Bugzilla 27 Sep '22

27 Sep '22

https://bugs.winehq.org/show_bug.cgi?id=48468 Bug ID: 48468 Summary: Add "Bronze" and "Garbage" top-10 lists to the appdb landing page Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: jonwsb(a)gmail.com Distribution: --- The top-10 lists on appdb.winehq.org are a very nice feature of the site. Their purpose of showing off what popular programs work in wine is very useful to new users and I think adding the "Bronze" and "Garbage" ratings to the page will also provide valuable information to new users as well as contributors. For new users it will give quick access to information on programs they may be planning on attempting to use with wine. For advanced users and contributors it will be a useful tool to gauge which programs need high quality testing and possibly give inspiration for developing patches to improve bronze and garbage rating entries. My biggest concern with adding these top-10 lists would be increasing the size of the page even more than it already is though it will also probably drive users of the appdb to vote for more applications overall. -- 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 45151] New: patches: 'git send-email' through Zoho SMTP causes patch queue to go berserk
by wine-bugs＠winehq.org 27 Sep '22

27 Sep '22

https://bugs.winehq.org/show_bug.cgi?id=45151 Bug ID: 45151 Summary: patches: 'git send-email' through Zoho SMTP causes patch queue to go berserk Product: WineHQ.org Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: kyle.auble(a)zoho.com Distribution: --- Created attachment 61339 --> https://bugs.winehq.org/attachment.cgi?id=61339 I'm starting to get embarrassed So I'll probably just start using my Gmail account for submissions to Wine anyways, but I've been having problems sending patches through Zoho. I've followed the instructions on https://wiki.winehq.org/Submitting_Patches and when running 'git send-email', there are no issues on my computer. I'm prompted for my SMTP password, git does its thing, and I've received an "OK / 250" return code every time. Small, one-off patches seem to make it through fine, but beyond that, then the wine-devel or the patch-list doesn't get them. Furthermore, Zoho delivers me a message saying that wine-devel can't be reached and that they'll keep retrying the delivery. And they do, which is where I think part of the problem might be coming from. --- In the first case, I tried sending a series of 7 patches. The first patch was a very short text change, the next five were larger batch substitutions on different strings, and the last one was a relatively short binary patch to delete five images. The first patch made it through pretty quickly, but the rest never showed up. To make things more confusing, I received Zoho notices that patches 5-7 couldn't reach the list and would be retried, but nothing about 2-4. Then a few hours later, the mailing list confirmed that patch 7 had made it through fine, but no sign of the middle 5. Since I had no notification from wine-devel or Zoho for patches 2-4, I tried resending patch 2 a couple times. Everything besides patches 1 & 7 seemed to just be falling into a black-hole though... until the next morning, every last patch I had sent (including the repeats of patch 2) was on both wine-devel and the patch-list, showing the original send dates, as if they had been there all along. --- In the second case, I had three large binary patches for deleting old images that have since been moved onto the wiki. I tried sending them one-at-a-time, 'git send-email' gave me an OK / 250, and they never made it to the list. This time Zoho sent me a notice saying that there was a fatal error with wine-devel's address, specifically "ResponseCode 421, Read timed out" The notice said they would keep retrying the delivery for 4 days, but then I didn't hear anything... until all of a sudden, today I see this on the patch queue (screenshot attached). I know I didn't resend either of these patches, much less 17 times. Weirdly enough, the wine-devel mailing list seems to understand what's going on a little better and only shows the message once. --- The one other pattern I have noticed is that it almost seems like the mailing list is clocking out for business hours. The first was on a Wed evening, but it wasn't until the next morning that everything suddenly appeared. The second time, I tried sending in my patches before Friday evening, but there was still no sign of them when I checked yesterday (Sun). Sure enough, they're all there today though. TL/DR: I know very little about how mail protocols work, and it could very well be on my mail service's end, but it almost seems like the mailing-list is actually receiving the emails. It then puts them in quarantine outside of normal work-hours, which doesn't seem like a problem in isolation. Somehow the sender is getting "delivery failed" codes though, and I only seem to get delivery receipts sporadically, despite turning on delivery receipts in my pipermail settings for wine-devel. -- 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

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 June 2021