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=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=47899
Bug ID: 47899
Summary: Review the VM name validation
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 web interface allows the creation of VMs that have dashes in their name.
But when untainting its parameters LibvirtTool considers such names to be
invalid, so that trying to revert these VMm fails.
There is a VM::Validate() method that should validate the VM name among others,
but obviously it cannot be used to check and untaint script parameters.
So the VM name validation criterions need to be checked and a standard function
provided.
--
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=47492
Bug ID: 47492
Summary: Typo in function name (__wine_spec_fini)
Product: Wine
Version: 4.12.1
Hardware: x86
OS: Solaris
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: tools
Assignee: wine-bugs(a)winehq.org
Reporter: evgeny.v.litvinenko(a)gmail.com
Created attachment 64875
--> https://bugs.winehq.org/attachment.cgi?id=64875
A patch example.
Hi all.
It looks like there is a typo in the file tools/winegcc/winegcc.c
The command
ggrep "[^_]_wine_spec_fini" -r *
in the source tree finds two places where __wine_spec_fini is with one
underscore in the begining.
I've attached a patch just to show the places with typo (I think it's a typo),
feel free to use it as you want.
Regards
evgeny.
--
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=17272
Summary: Zmodeler: Icons and overall GUI blinky
Product: Wine
Version: 1.1.14
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: gaming4jc2(a)yahoo.com
Created an attachment (id=19272)
--> (http://bugs.winehq.org/attachment.cgi?id=19272)
Simple log of fixme's in the console
Zmodeler is not quite in full working condition (but tons better than prior to
1.1.14). When using the buttons on the Main Toolbar the icons which
occasionally disappear and overall 3D performance is rather slow. You can
mouseover the icons and they will reappear, but it isn't overly practical...
Attached is a log. I believe it has something to do with"LockWindowUpdate".
--
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.
http://bugs.winehq.org/show_bug.cgi?id=30827
Bug #: 30827
Summary: Uninitialized memory reference in
create_icon_pixmaps() -> GetDIBits() ->
bitmapinfoheader_from_user_bitmapinfo()
Product: Wine
Version: 1.5.5
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: gdi32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
Classification: Unclassified
While looking at bug 30826, I saw
Conditional jump or move depends on uninitialised value(s)
at bitmapinfoheader_from_user_bitmapinfo (dib.c:177)
by GetDIBits (dib.c:1210)
by create_icon_pixmaps.isra.8 (window.c:883)
create_icon_pixmaps calls GetDIBits with bits=NULL and a mostly uninitialized
info, but bitmapinfoheader_from_user_bitmapinfo() assumes that biCompression
has already been initialized.
gdi32/dib.c:
149 static BOOL bitmapinfoheader_from_user_bitmapinfo( BITMAPINFOHEADER
*dst, const BITMAPINFOHEADER *info )
150 {
...
166 else if (info->biSize >= sizeof(BITMAPINFOHEADER)) /* assume
BITMAPINFOHEADER */
167 {
168 *dst = *info;
169 }
...
176 dst->biSize = sizeof(*dst);
177 if (dst->biCompression == BI_RGB || dst->biCompression ==
BI_BITFIELDS)
178 dst->biSizeImage = get_dib_image_size( (BITMAPINFO *)dst );
1187 INT WINAPI GetDIBits(
1188 HDC hdc, /* [in] Handle to device context */
1189 HBITMAP hbitmap, /* [in] Handle to bitmap */
1190 UINT startscan, /* [in] First scan line to set in dest bitmap */
1191 UINT lines, /* [in] Number of scan lines to copy */
1192 LPVOID bits, /* [out] Address of array for bitmap bits */
1193 BITMAPINFO * info, /* [in,out] Address of structure with bitmap
data */
1194 UINT coloruse) /* [in] RGB or palette index */
1195 {
...
1208 /* Since info may be a BITMAPCOREINFO or any of the larger
BITMAPINFO structures, we'll use our
1209 own copy and transfer the colour info back at the end */
1210 if (!bitmapinfoheader_from_user_bitmapinfo( &dst_info->bmiHeader,
&info->bmiHeader )) return 0;
....
1212 if (bits &&
1213 (dst_info->bmiHeader.biCompression == BI_JPEG ||
dst_info->bmiHeader.biCompression == BI_PNG))
winex11.drv/window.c:
868 static BOOL create_icon_pixmaps( HDC hdc, const ICONINFO *icon, struct
x11drv_win_data *data )
869 {
870 char buffer[FIELD_OFFSET( BITMAPINFO, bmiColors[256] )];
871 BITMAPINFO *info = (BITMAPINFO *)buffer;
...
881 info->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
882 info->bmiHeader.biBitCount = 0;
883 if (!(lines = GetDIBits( hdc, icon->hbmColor, 0, 0, NULL, info,
DIB_RGB_COLORS ))) goto failed;
Note that GetDIBits is careful to avoid referencing biCompression itself
when bits is NULL, but the function it calls doesn't know whether bits is NULL.
(bug 30266 is nearby but doesn't seem related?)
--
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.
http://bugs.winehq.org/show_bug.cgi?id=35937
Bug ID: 35937
Summary: The file crashed upon loading the program.
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: carlino.designs(a)gmail.com
Created attachment 47995
--> http://bugs.winehq.org/attachment.cgi?id=47995
Error log file for eDCAA.exe
The file crashed upon loading the program.
The file can be downloaded at:
http://brightemo.co.uk/download/eDCAA.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.
http://bugs.winehq.org/show_bug.cgi?id=27570
Summary: Aliens Vs Predator 2 Demo is temporary confined
ingame.
Product: Wine
Version: 1.3.22
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: andrew.millington(a)gmail.com
I've tried the marine demo at the start the mouse movement is confined like bug
#6971 until you right click or over time, it works as per usual after this plus
"Automatically capture the mouse input in full-screen window" changes nothing.
Make fmv videos not accessible to speed up testing.
I haven't tested when you start the next level due to being a demo.
--
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.