http://bugs.winehq.org/show_bug.cgi?id=10154
Summary: Reel Deal Vegas Casino seems to lock up on startup
Product: Wine
Version: CVS/GIT
Platform: Other
URL: http://www.phantomefx.com/vegas_mania_overview.asp
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: wine-misc
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
To repeat: install the two-cd app, then do
$ cd ~/.wine/drive_c/Program Files/Phantom EFX/OnlineCasino
$ wine Launcher/OLCLauncher.exe
It sits in a tight loop, calling
0009:Call user32.PeekMessageA(0033fae8,00010024,00000000,00000000,00000001)
ret=0043053a
0009:Call
winex11.drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,000004ff,00000000)
ret=7ec2501a
0009:Ret winex11.drv.MsgWaitForMultipleObjectsEx() retval=00000102
ret=7ec2501a
0009:Ret user32.PeekMessageA() retval=00000000 ret=0043053a
and a few other things over and over.
Another way to try to run the game is to do
$ wine bin/Prelauncher.exe
This at least puts up a window that has a spinny
ascii art "Searching for Sessions" message,
but none are found. On the console one sees
fixme:dpnet:IDirectPlay8ClientImpl_EnumHosts (0x129938):((nil),0x64aba8,0):
Stub
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20621
Summary: DoubleCAD XT-1.1: installation is OK, then the program
opens, and it's immediately frozen [X11 still works]
Product: Wine
Version: unspecified
Platform: Macintosh
URL: http://www.DoubleCAD.com
OS/Version: Mac OS X 10.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: riek(a)pandora.be
I have installed DoubleCAD in WINE (with the terminal) .
After registration with an activation code for the free version,
which I received by email after contact on the website: "www.DoubleCAD.com",
WINE asked for "GECKO" .
I agreed an installed,
the program opens, with "X11" .
But nothing worked,
no menu, no help (F1-button) .
To quit the frozen program, I had to quit "X11" .
X11 was still running properly .
--
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=37145
Bug ID: 37145
Summary: Can not submit confirmation string on the website
Product: WineHQ.org
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: christopherwuy(a)gmail.com
When I recieved confirmed string and logined the website
https://www.winehq.org/mailman/confirm/wine-devel/ to submit, it only refreshes
the input field of confirmation string and do nothing.
A friend had tried it and he met the same problem too.
--
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=32856
Bug #: 32856
Summary: Add a VM running the tests from a non c: drive
Product: Wine-Testbot
Version: unspecified
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: fgouget(a)codeweavers.com
Classification: Unclassified
kernel32:volume skips some tests unless it is run from a non c: drive:
volume.c:402: Tests skipped: Please re-run from another device than C:
--
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=35576
Bug ID: 35576
Summary: WineTestBot leaks staging files
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
Classification: Unclassified
Currently the tools/testbot/var/staging directory of my test environment has
more than 10000 files which is way more than the number of current tests. There
are probably two issues:
* The janitor script purges all tests that are more than a week old. Yet a lot
of files are older than that. It's possible that the staging files should not
be there any more once a test has been run and thus by the time the Janitor
script purges it. However the Janitor script should probably still ensure that
the staging files get purged too.
* It seems that whenever WinePatchesWebSubmit.pl is run it creates a set of
staging files. However if the Engine is stopped those won't be processed
immediately and thus the next time WinePatchesWebSubmit.pl runs it will create
a new set of staging files, presumably for the same set of patches. It's likely
that this is also causes a leak, probably exacerbated by the Janitor script.
Fortunately the official WineTestBot is rarely offline though.
--
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=35946
Bug ID: 35946
Summary: Cannot mark a VM for maintenance if it is running a
task
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
To mark a VM for maintenance one sets its status to 'maintenance'.
The problem is that when a VM runs a task its status is 'running' and once its
done the task script blindly sets its status to 'dirty' hence overwriting the
'maintenance' status.
Note that even setting the VM role to 'retired' does not work although the task
script does not explicitly change it. It seems like the whole VM's row gets
rewritten when the the task script saves the new status.
So the task script should refresh its view of the VM status and check that it's
still 'running' before changing it. That still leaves open a small window for
races but that's probably acceptable.
The same problem exists in the RevrtVM.pl script with the 'reverting' and
'sleeping' states.
--
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=34965
Bug #: 34965
Summary: New Testbot doesn't correctly sets the time for the
VMs so e.g. winhttp is failing
Product: Wine-Testbot
Version: unspecified
Platform: x86
URL: https://newtestbot.winehq.org/JobDetails.pl?Key=3484
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: nerv(a)dawncrow.de
CC: fgouget(a)codeweavers.com
Classification: Unclassified
winhttp tests a secure connection to google.com, but fails because the VM time
out of the certificates time range:
winhttp:winhttp start - -
winhttp.c:806: WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID
winhttp.c:859: Test failed: failed to send request 12175
winhttp.c:870: ftStart Wednesday, November 06, 2013 2:00:40 PM
winhttp.c:874: ftExpiry Thursday, March 06, 2014 12:00:00 AM
winhttp.c:878: local Friday, October 25, 2013 9:23:32 AM
after hacking this into the tests before the skip:
size = sizeof(info);
ret = WinHttpQueryOption(req, WINHTTP_OPTION_SECURITY_CERTIFICATE_STRUCT,
&info, &size );
ok(ret, "failed to retrieve certificate info %u\n", GetLastError());
{
SYSTEMTIME st;
char exdate[255], extime[255];
FileTimeToSystemTime( &info.ftStart, &st );
GetDateFormatA( LOCALE_USER_DEFAULT, DATE_LONGDATE, &st, NULL, exdate, 255 );
GetTimeFormatA( LOCALE_USER_DEFAULT, 0, &st, NULL, extime, 255 );
trace( "ftStart %s %s\n", exdate, extime );
FileTimeToSystemTime( &info.ftExpiry, &st );
GetDateFormatA( LOCALE_USER_DEFAULT, DATE_LONGDATE, &st, NULL, exdate, 255 );
GetTimeFormatA( LOCALE_USER_DEFAULT, 0, &st, NULL, extime, 255 );
trace( "ftExpiry %s %s\n", exdate, extime );
GetLocalTime(&st);
GetDateFormatA( LOCALE_USER_DEFAULT, DATE_LONGDATE, &st, NULL, exdate, 255 );
GetTimeFormatA( LOCALE_USER_DEFAULT, 0, &st, NULL, extime, 255 );
trace( "local %s %s\n", exdate, extime );
}
--
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=31798
Bug #: 31798
Summary: Some sort of anti-spam measure for testbot signups
Product: Wine-Testbot
Version: unspecified
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: scott(a)open-vote.org
Classification: Unclassified
We get maybe 2-3 spam applications per day now, from automated
sign-up-for-anything bots.
A simple captcha (even a homegrown "enter the text 'I am human' one") would
probably be sufficient.
--
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=26443
Summary: GitWeb: 'patch' links within a commitdiff don't work
Product: WineHQ.org
Version: unspecified
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: www-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ken(a)codeweavers.com
On a commitdiff page such as
<http://source.winehq.org/git/wine.git/commitdiff/0b396208db68c950725adae49c…>,
there are "patch" links next to each changed file in the summary (along with
"blob", "blame", and "history"). Those patch links should link to an anchor
within the page. However, they're currently broken, being something like
<http://source.winehq.org/git/gitweb.cgi#patch4>. The anchor is right, but the
page URL is not for the current page.
I have tested with Firefox 3.6.15 and Safari 5.0.3 on Mac OS X 10.6, although I
have no reason to believe the browser or OS affect the issue.
--
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.