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.
https://bugs.winehq.org/show_bug.cgi?id=45869
Bug ID: 45869
Summary: Crackling sound With PulseAudio
Product: Wine-staging
Version: 3.15
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ahmed.com(a)aol.com
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 62367
--> https://bugs.winehq.org/attachment.cgi?id=62367
wine.log
My laptop produces crackling sound everytime I use Wine, and that happens with
all the games not a specific game.
What I've tried:
/etc/pulse/default.pa
load-module module-udev-detect tsched=0 ignore_dB=1
/etc/pulse/daemon.conf
; realtime-priority = 9
; flat-volumes = no
; default-fragments = 2
; default-fragment-size-msec = 125
PULSE_LATENCY_MSEC=60
Winetricks ==> change settings ==>> sound=alsa
But no difference at all.
I added a wine log using:
WINEDEBUG=+dsound,+pulse,+alsa wine .⁄witcher.exe &>wine.log
System info :
Distro: Manjaro Linux
Desktop: KDE Plasma 5.13.5
Kernel: 4.14.70-1
System: HP ProBook 450 G1
Sound device: Intel 8 Series/C220 Series High Definition Audio
Audio driver: snd_hda_intel
--
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=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.
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.
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.
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.
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.
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.
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.
https://bugs.winehq.org/show_bug.cgi?id=39425
Bug ID: 39425
Summary: Improve resilience to VM host outages
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: ---
Currently the WineTestBot gets stuck when the connection to the libvirt server
on the VM hosts is broken. This includes cases where the libvirt server is
restarted, the VM hosts is rebooted or cases where there's a network outage.
The reason is that the Engine queries the status of the VMs itself in some
circumstances. This creates a TCP connection which is never recreated in case
it breaks.
The proper fix is to banish all such queries from the Engine: not just to fix
this issue but also because some of these operation can be long (a few seconds)
and block the main loop of the single-threaded Engine, which can in turn cause
the website to lag.
--
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.