wine-bugs May 2018

wine-bugs@winehq.org

1 participants
8173 discussions

[Bug 37010] New: DYMO Stamps "Unable to connect to postage transaction server" with wine-mono
by wine-bugs＠winehq.org 04 Nov '18

04 Nov '18

https://bugs.winehq.org/show_bug.cgi?id=37010 Bug ID: 37010 Summary: DYMO Stamps "Unable to connect to postage transaction server" with wine-mono Product: Wine Version: 1.7.23 Hardware: x86 URL: http://sites.dymo.com/Promotions/Pages/DYMOStamps.aspx ?locale=enUS OS: Linux Status: NEW Severity: normal Priority: P2 Component: mscoree Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Depends on: 31686 Follow up to bug 31687. You'll need native gdiplus for bug 31686. Optionally, apply https://source.winehq.org/patches/data/105843. The app installs fine, and with native gdiplus, starts up. But when you try to login, the application cannot connect to the server. Terminal shows one mscoree fixme: fixme:mscoree:ConfigFileHandler_startElement Unknown element L"configSections" in state 2 With native dotnet20, it will attempt to connect, then fails with 'This account is not active'. Trying to login via the website shows the same problem, so that's okay. But wine-mono should fail the same way. I'm using an archived installer: austin@aw25 ~/oldbugs/31687 $ sha1sum DYMOstampsWebSetup.exe 6f96fbdc9806effa499edba7e89329534b5901a7 DYMOstampsWebSetup.exe austin@aw25 ~/oldbugs/31687 $ du -h DYMOstampsWebSetup.exe 3.5M DYMOstampsWebSetup.exe the current version of the program appears to have other .Net/Mono issues -- 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 8

[Bug 31687] New: DYMO Stamps can't connect to its server
by wine-bugs＠winehq.org 04 Nov '18

04 Nov '18

http://bugs.winehq.org/show_bug.cgi?id=31687 Bug #: 31687 Summary: DYMO Stamps can't connect to its server Product: Wine Version: 1.5.12 Platform: x86 URL: http://sites.dymo.com/Promotions/Pages/DYMOStamps.aspx ?locale=enUS OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Depends on: 31685, 31686 Classification: Unclassified Created attachment 41656 --> http://bugs.winehq.org/attachment.cgi?id=41656 WINEDEBUG=crypt,chain,context,secur32 Install the app. You'll need native gdiplus for bug 31686. After that, you can get native hid, for bug 31685. I also installed dotnet20, to verify that it wasn't a mscoree fixme to blame, but the problem happens either way. Start it up, and it asks for your credentials. Put them in, and click next. That gives an error: The remote certificate is invalid according to the validation procedure. terminal output doesn't show much relevant. Tried native wininet/winhttp, which then in turns shows a few fixme's for crypt32/secur32/winsock. If you add in native crypt32, you get: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. and with native secur32 as well: The requested security package is not supported. Not sure what to try next. The initial problem seems to indicate crypt32 or secur32, so hopefully this log will help: WINEDEBUG=crypt,chain,context,secur32 -- 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.

1 9

[Bug 39350] New: Alone in the Dark: The New Nightmare (GOG.com) hangs on start when WRITECOPY enabled
by wine-bugs＠winehq.org 04 Nov '18

04 Nov '18

https://bugs.winehq.org/show_bug.cgi?id=39350 Bug ID: 39350 Summary: Alone in the Dark: The New Nightmare (GOG.com) hangs on start when WRITECOPY enabled Product: Wine-staging Version: unspecified Hardware: x86 URL: http://www.gog.com/game/alone_in_the_dark_the_new_nigh tmare OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: gyebro69(a)gmail.com CC: michael(a)fds-team.de, sebastian(a)fds-team.de Distribution: --- I have this problem with the GOG.com version of the game, but can't reproduce it with the original demo version. After starting the game with alone4.exe, it switches screen resolution then hangs with an empty black screen and 100% CPU usage. Plain terminal output doesn't show anything. The game starts properly when STAGING_WRITECOPY variable is unset. wine-1.7.51-225-g3966aff Fedora 22 32-bit -- 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 6

[Bug 45222] New: How do I remove my WineHQ Bugzilla Account
by wine-bugs＠winehq.org 04 Nov '18

04 Nov '18

https://bugs.winehq.org/show_bug.cgi?id=45222 Bug ID: 45222 Summary: How do I remove my WineHQ Bugzilla Account Product: WineHQ Bugzilla Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs(a)winehq.org Reporter: rexax007(a)gmail.com CC: austinenglish(a)gmail.com Distribution: --- How do I remove my WineHQ Bugzilla Account -- 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 4

[Bug 45201] New: "Task Lists" shows "Wine 2.0"
by wine-bugs＠winehq.org 04 Nov '18

04 Nov '18

https://bugs.winehq.org/show_bug.cgi?id=45201 Bug ID: 45201 Summary: "Task Lists" shows "Wine 2.0" Product: WineHQ Bugzilla Version: unspecified Hardware: Other OS: other Status: UNCONFIRMED Severity: trivial Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs(a)winehq.org Reporter: manzisam(a)gmail.com CC: austinenglish(a)gmail.com Observation bugzilla shows "Wine 2.0" under the "Task Lists" and also shows the text: ------------------------------------ Current Bug Task Lists The bugs we are currently working on are organized into Task lists. Wine 2.0 These bugs are scheduled to be fixed before Wine 2.0 is released. ------------------------------------ according to the winehq website 2.0 was released ages ago and the two current versions are (Stable:Wine 3.0.1) and (Development:Wine 3.8) My suggestion is remove it as obviously no has enough time to update with the frequency that it as requires. Thanks for wine :) -- 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 4

[Bug 43234] New: Allow users to show all full logs
by wine-bugs＠winehq.org 04 Nov '18

04 Nov '18

https://bugs.winehq.org/show_bug.cgi?id=43234 Bug ID: 43234 Summary: Allow users to show all full logs Product: Wine-Testbot Version: unspecified Hardware: Other OS: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: z.figura12(a)gmail.com Currently it's possible to expand one log at a time to show not only the failing lines but also the trace() output. It would be nice if we had a way to see them all at once, though. Of course the user does get the full results e-mailed to them, but the e-mail can take a while to go through, and also it might be good if other people can get the full logs of a test they didn't run (e.g. because it was linked to by the user.) -- 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 44785] New: FTP server (security ?) bug
by wine-bugs＠winehq.org 04 Nov '18

04 Nov '18

https://bugs.winehq.org/show_bug.cgi?id=44785 Bug ID: 44785 Summary: FTP server (security ?) bug Product: Packaging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-packages Assignee: wine-bugs(a)winehq.org Reporter: luc.bournaud(a)hotmail.fr CC: michael(a)fds-team.de, sebastian(a)fds-team.de Distribution: --- I'm making a tool to download Wine from FTP server. I've got a little surprise when listing versions on your FTP server, all directories under "ftp://ftp.winehq.org/pub/wine/source" are "perm=fle" (I can rename the directory) and all files are "perm=adfr" (I can anonymously edit Wine on your servers !). I don't know if it's just a minor bug or a real huge security issue... -- 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 9

[Bug 41723] New: Install ucrtbase.dll on at least one of the machines
by wine-bugs＠winehq.org 04 Nov '18

04 Nov '18

https://bugs.winehq.org/show_bug.cgi?id=41723 Bug ID: 41723 Summary: Install ucrtbase.dll on at least one of the machines Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: piotr.caban(a)gmail.com Distribution: --- We have tests for ucrtbase.dll in wine but currently they are never run on testbot. It would be nice to install the dll on at least one of the machines. -- 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 39487] New: Make step dependencies more flexible
by wine-bugs＠winehq.org 04 Nov '18

04 Nov '18

https://bugs.winehq.org/show_bug.cgi?id=39487 Bug ID: 39487 Summary: Make step dependencies more flexible 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 jobs are split into steps and tasks. * The steps are numbered and must be executed in order. Each step has an associated file. * Each step has one or more tasks which can all be run in parallel. Typically the first step is the build step associated to the patch. It produces the 32 and 64 bit executables for the following steps hence why it has to be executed first. When it fails the other steps are skipped which is not the case for the other steps. So the general structure is: Step 1 - patch.diff - Build Step 2 - test_32.exe - One task per VM Step 3 - test_64.exe - One task per VM So one source of inefficiency is that the 64 bit tests cannot start until all the 32 bit tests have completed. It does not necessarily make the overall job execution longer but it can leave a VM host idle while it waits for the remaining 32 bit tests to complete. And if a developer is watching the job's page he will not know of 64 bit failures until then. So while the build step has to come before all others, that condition should be relaxed for the other steps. The database schema presented in bug 39412 adds a DependencyNo field to the Step table so that step dependencies can be made explicit. This would allow making both test steps depend on build one. Note that with this scheme a given step could not directly depend on multiple other steps but that does not seem needed. It would also make more explicit the fact that test steps cannot be run if the build one fails instead of hard-coding that behavior in Jobs::UpdateStatus(). -- 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 45025] New: Multi-dll patches vs patches website
by wine-bugs＠winehq.org 04 Nov '18

04 Nov '18

https://bugs.winehq.org/show_bug.cgi?id=45025 Bug ID: 45025 Summary: Multi-dll patches vs patches website 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 integrates with Wine's patch tracking website by providing it with the job id of the job corresponding to patches that impact the tests. This makes it possible to automatically flag patches that cause new test failures on Windows. https://source.winehq.org/patches/ However when a patch modifies the tests of multiple dlls (for instance d3d8.dll and d3d9.dll) the TestBot creates one job per dll. This cannot work with the patches website which can only deal with one job per patch. In theory putting all the relavant tasks would be doable since there should be no collision between the test executables. The reasons for the current situation are: * The build step only knows how to build one 3é bit and one matching 64 bit test executable. So in the d3d8 and d3d9 case it would be unable to create both d3d8_test.exe and d3d9_test.exe. * Each step in a job implicitly dependended on the previous step. So a failure to build d3d8_test.exe would have caused the d3d9 tests to be skipped too. However this special behavior was specific to the first step so without modification a failure to build the d3d9 test executable in step 2 would likely not have prevented the TestBot from trying to run the d3d9 tests. However now the TestBot supports proper dependencies between steps. So it's possible to have the d3d8 tests depend on the d3d8 build and the d3d9 tests depend on the d3d9 build, and have both be completely independent. There is also progress towards simplifying the build task which would likely make it simpler to deal with building all the test executables in one task. However this would cause all the builds to succeed or fail together because all the other steps would depend on that one build step. So for instance if the d3d9_test.exe build fails, no test would be run even if d3d8test.exe was successfully built. That may be acceptable though since the patch would need to be resubmitted anyway. -- 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 May 2018