https://bugs.winehq.org/show_bug.cgi?id=45216
Bug ID: 45216
Summary: Alien: Isolation crashes on startup
Product: Wine
Version: 3.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: moihack.inside(a)gmail.com
Distribution: ArchLinux
Created attachment 61439
--> https://bugs.winehq.org/attachment.cgi?id=61439
Alien:Isolation terminal output
Alien: Isolation (Steam version) crashes on startup.
There is an attempt for the game to load as a process named AI.exe is created
and a window pops up on a black screen but with the mouse cursor changing to
the in-game one. So the game at least attempts to boot up.
Specifically for Arch Linux which I use, there is a "trick" to get this game
running.
If you install the package "wine-staging-nine" from the official repositories
here : https://www.archlinux.org/packages/multilib/x86_64/wine-staging-nine/
the game boots correctly.
It does not boot up with plain wine-staging or vanilla wine + gallium nine
patches. So it probably needs a mix of patches from both projects.
I'm attaching a terminal output below.
GPU used: Radeon HD 6870
--
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=48629
Bug ID: 48629
Summary: valgrind shows dependency on uninitialized memory in
gdi32/dib.c
Product: Wine
Version: 5.0-rc6
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: winex11.drv
Assignee: wine-bugs(a)winehq.org
Reporter: dark.shadow4(a)web.de
Distribution: ---
Created attachment 66480
--> https://bugs.winehq.org/attachment.cgi?id=66480
valgrind log
See attachment.
--
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=48241
Bug ID: 48241
Summary: PACE license manager installer dies with Error: -1627
Function failed
Product: Wine
Version: 4.21
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msi
Assignee: wine-bugs(a)winehq.org
Reporter: emiel(a)kollof.nl
Distribution: ---
Installation seems to die here:
01de:err:msi:ITERATE_StartService Failed to start service
L"PaceLicenseDServices" (6)
01de:err:msi:execute_script Execution of script 0 halted; action
L"StartServices" returned 1627
01de:err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize"
returned 1627
00c9:err:ole:ClientRpcChannelBuffer_SendReceive called from wrong apartment,
should have been 0xca000001de
--
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.
http://bugs.winehq.org/show_bug.cgi?id=17101
Summary: Cancelling text with Scientific Workplace leaves last
character
Product: Wine
Version: 1.1.13
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: loic.grenie(a)gmail.com
Created an attachment (id=18937)
--> (http://bugs.winehq.org/attachment.cgi?id=18937)
Screenshots
When I delete text under Scientific Workplace, the end of the line is not
treated correctly. Was is most evident is that the last character(s) is(are)
not canceled.
I attach a vertical concatenation of 3 screenshots:
the first is the state before hitting backspace: I typed "abcdefghijkl" and
added an inline image,
the second is after hitting backspace (I cancel the "g"); notice how the last
"kl" are not correctly canceled and the image is not moved to the left
and the third is how it should have looked.
No error message is displayed while hitting backspace (it complains about IME
all the time but I think it's no big deal).
I have seen this problem at least in versions 1.0.1 (under Debian testing,
Ubuntu hardy and intrepid, both 32 and 64 bits) and 1.0.13 (Debian testing 64
bits). The situation is even worse under Ubuntu intrepid (32 bits OS, Wine
v1.0.1) as text disappears as soon as it is typed (Esc redisplays it briefly).
I can live with the image (visible at the end of the line) not correctly
positioned after backspace (it seldom occurs), but the last character not
canceled is a real (visual) pain.
I can test anything you wish and I understand programming/debugging.
Thank you for any help.
SurJector
--
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.
https://bugs.winehq.org/show_bug.cgi?id=48659
Bug ID: 48659
Summary: Job details page: Add links to the first error in a
report
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: ---
When looking at a full WineTest report on the TestBot website finding the
errors can require a lot of scrolling and there is a risk of skipping over
them.
The cache .errors files contain the line of each error and error group.
This makes it possible to add links to the errors:
* The first report line would contain a link pointing to the first report error
(for instance in the form of a down arrow at the start of the line).
* Errors would contain links to the previous/next errors, or to the first/last
report line.
* The last report line would link to the last report error.
Once the first draft is ready the link chain may be tweaked:
* The first line of test units containing errors, could be added to it.
* A second chain link to be set up with only the new failures.
--
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=48658
Bug ID: 48658
Summary: Fix error handling in the WineRun* scripts
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: ---
Over time error handling in the WineRun* scripts has become complex and
inconsistent. It's in need of a serious cleanup, particular so that errors can
be reliably identified in the testbot.log file and shown on the JobDetails
page.
There are three places where the WineRun* scripts can send errors:
* To the global 'var/log' log file.
Sending errors to the global file makes sense for errors which could be
relevant to other operations on that VM such as the preceding or following
revert.
* To the per-task 'testbot.log' file.
This is where most errors should go for long term storage.
* To stderr which is redirected to 'testbot.log' nowadays.
Then there are a number of functions that report errors:
* LogMsg()
This adds a message to the global log (errors and others alike).
It is used to log the startup and exit of the WineRun* scripts in the global
log, but also to save some errors there.
* Error()
Prints the error on stderr if --log-only is not specified, and sends them to
the global log (via LogMsg()). In particular things like usage errors thus end
up in the global log which probably does not make sense.
* LogTaskError()
Explicitly opens testbot.log and appends to it. It should really print to
stderr instead. But some calls to LogTaskErrors
* FatalError()
The main point of FatalError() is that it invokes WrapUpAndExit() with
appropriate parameters.
But it also sends the error message to both the global log and testbot.log
(via LogTaskError()). That's probably not appropriate.
* FatalTAError()
This is a specialized form of FatalError() which also notifies the
administrator of network issues.
That's ok except that depending on the codepath it may end up calling any of
Error(), LogMsg(), LogTaskError() or FatalError().
--
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=8439
François Gouget <fgouget(a)codeweavers.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|fgouget(a)codeweavers.com |wine-bugs(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.
https://bugs.winehq.org/show_bug.cgi?id=47042
Bug ID: 47042
Summary: Ignore replies to patchset parts
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 treats every email as a potential patch.
This makes sense as replies to a patch could be a new version for that patch
which means it should be tested.
But replies to parts of patches are different. Here is what happened due to the
failure to recognize this.
I'm not sure why but the TestBot must have received the following emails in
this order (this is not the order of the send times but it matches the order in
which I received the emails in my inbox):
* [PATCH 1/5] ntoskrnl.exe: Implement PsLookupThreadByThreadId.
https://www.winehq.org/pipermail/wine-devel/2019-April/144085.html
Part 1/5 in a patch series. The TestBot created a PendingPatchSet object to
track the different parts.
* Re: [PATCH 1/5] ntoskrnl.exe: Implement PsLookupThreadByThreadId.
https://www.winehq.org/pipermail/wine-devel/2019-April/144088.html
The TestBot decided this looked like a patch because the HTML version
contains lines that start with "+++ ". Thus it treated this email as a new
version of the previous patch, like it usually does, and replaced patch 1 in
the PendingPatchSet.
* Re: [PATCH 2/5] ntoskrnl.exe: Implement KeAreApcsDisabled using critical
region functions.
https://www.winehq.org/pipermail/wine-devel/2019-April/144086.html
The TestBot created a job to test this patch but used the updated part 1 of
the patch set which in fact was an HTML email. This resulted in an invalid
patch and thus a failure to apply.
The TestBot probably did two things wrong:
1. It took a patch from an HTML attachment.
The TestBot already rejects those but somehow the $Part->effective_type ne
"text/html" test in Patch::NewPatch() did not work.
2. It replaced part 1 of a patchset with a new version.
One cannot send a new version of a part in a patchset: the whole patchset
must be resubmitted (*). So the TestBot should never replace a part in a
patchset.
It looks like this check should be done in PendingPatchSets::NewSubmission()
near the $Set->Parts->GetItem($PartNo) call.
The issue here is that we may receive emails out of order. So we could
receive a reply to part 1, and thus add it as part 1, before we receive the
actual email for part 1.
(*) Otherwise we'd have to keep the patchsets around and create new jobs for
all parts that follow the replaced part. And if multiple parts are replaced...
madness!
--
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=48031
Bug ID: 48031
Summary: Limit the size of the task logs
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 does not check the size of the reports and logs it downloads from
the VMs. These could be quite big and are even more likely to get big if
setting WINEDEBUG is allowed. So there should be a limit.
The TestAgent GetFile() API has no provision for putting a limit on the size of
the file being retrieved. But checking the size against a limit would come
quite naturally if the files are retrieved one chunk at a time (see bug 48030).
Note that the Wine rebuild logs are quite big (11MB).
--
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=48644
Bug ID: 48644
Summary: Kodak EasyShare installer doesn't populate list of
countries
Product: Wine
Version: 5.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: oleg.kuznetsov(a)metamint.ru
Distribution: ---
Created attachment 66502
--> https://bugs.winehq.org/attachment.cgi?id=66502
Combo box on Vista
While Kodak EasyShare is impossible to download and use (see: bug 17294 comment
25 ), I found one issue with the installer/downloader: it doesn't populate list
of countries on one of the steps.
Steps to reproduce:
1) Start the installer. On Language selection screen, press "Next"
2) On the next screen, accept License Agreement and press "Next"
Expected result:
On the appeared screen, there is should be a combo box "Select your country"
with a list of countries (on Windows Vista it is populated)
Actual result:
The combo box is empty, nothing in the terminal.
wine version:
wine-5.2-203-gb253bd6
sha1sum install_easyshare_8.2.0.exe
d4725af6e42d49b2dfee83a24979ece235d66fd5 install_easyshare_8.2.0.exe
--
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.