April 2014 - Wine-Bugs - list.winehq.org

[Bug 35576] New: WineTestBot leaks staging files
by wine-bugs＠winehq.org Nov. 13, 2014

Nov. 13, 2014

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.

1 3

[Bug 35946] New: Cannot mark a VM for maintenance if it is running a task
by wine-bugs＠winehq.org Nov. 13, 2014

Nov. 13, 2014

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.

1 2

[Bug 34965] New: New Testbot doesn't correctly sets the time for the VMs so e.g. winhttp is failing
by wine-bugs＠winehq.org Nov. 13, 2014

Nov. 13, 2014

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.

1 2

[Bug 31798] New: Some sort of anti-spam measure for testbot signups
by wine-bugs＠winehq.org Nov. 13, 2014

Nov. 13, 2014

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.

1 2

[Bug 26443] New: GitWeb: 'patch' links within a commitdiff don't work
by wine-bugs＠winehq.org Nov. 13, 2014

Nov. 13, 2014

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.

1 7

[Bug 31781] New: Add VMs with multiple network interfaces
by wine-bugs＠winehq.org Nov. 13, 2014

Nov. 13, 2014

http://bugs.winehq.org/show_bug.cgi?id=31781 Bug #: 31781 Summary: Add VMs with multiple network interfaces 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 Some Wine developers have reported a need to have at least some VMs with multiple network interfaces for some of Wine's conformance tests. For instance: http://www.winehq.org/pipermail/wine-devel/2012-August/096875.html -- 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 8

[Bug 31780] New: Add VMs with virtual CDs
by wine-bugs＠winehq.org Nov. 13, 2014

Nov. 13, 2014

http://bugs.winehq.org/show_bug.cgi?id=31780 Bug #: 31780 Summary: Add VMs with virtual CDs 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 Some Wine developers have reported a need to have at least some VMs with a CD in the virtual drive for some of Wine's conformance tests. For instance: http://www.winehq.org/pipermail/wine-devel/2012-August/096873.html This would be quite easy to do. Mostly, all that's needed is the appropriate CD images and then configuring specific VMs to use them (one VM could even have multiple CD drives). I can set this up when configuring the VMs for the new Wine TestBot, however someone else will have to provide the CD images, or, even better scripts to generate them. -- 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 5

[Bug 33788] New: The VMs clock is off
by wine-bugs＠winehq.org Nov. 13, 2014

Nov. 13, 2014

http://bugs.winehq.org/show_bug.cgi?id=33788 Bug #: 33788 Summary: The VMs clock is off 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 The issue is that WineTestBot restores running VM snapshots. So when these start their clock is still set to whenever the snapshot was taken which can be months ago. VMware had a special driver that took care of updating the VM clock automatically when starting the snapshot but QEmu/KVM does not. The VMs may synchronize with an Internet clock eventually depending on thet particular Windows' default configuration and how often they do so. This has an impact on some tests and causes failures. My understanding is that in particular the certificate tests check that some online certificates have expired. But obviously if the VM's clock is still running months behind it may not consider the certificate to have expired yet. These tests should arguably compare the system clock with the certificate expiration date and realize that the certificate has not expired yet. However that's not the point of the test. The solution is to force the VM clock to resynchronize by running a special command when we start the snapshot. These commands depend on the Windows version :-( Windows >= 2003 w32tm /config /syncfromflags:manual /manualpeerlist:0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org Windows XP net time /setsntp:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org" -- 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 5

[Bug 26608] New: AvaSoft: doesn't run
by wine-bugs＠winehq.org Nov. 12, 2014

Nov. 12, 2014

http://bugs.winehq.org/show_bug.cgi?id=26608 Summary: AvaSoft: doesn't run Product: Wine Version: 1.2.2 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: kotya.karapetyan(a)gmail.com Created an attachment (id=33873) --> (http://bugs.winehq.org/attachment.cgi?id=33873) Log of installing and running in terminal. After freshly installing Wine 1.2.2 using 'sudo apt-get install wine' on Ubuntu 10.10, I ran the Windows program installer from a CD with 'wine start setupAvaSoftUSB2.EXE'. The installer reported some problems, see attachment. However, the program icon appeared on the desktop. When double-clicking it, the program started to run, but then the window 'Program Error' appeared with the suggestion to report this bug here. I rerun it in Terminal, the log is also shown in the attachment. In both cases (in the end of installation and after closing the launched program), Wine stopped doing anything after showing the last line in log. In GUI, the following errors are shown when the program stops working: 'Application Error: Exception EExternalException in module ntdll.dll at 0002D908. External exception C0000025.' Then 'avaspec76usb2: Access violation at address 7D7A5540*. Read of address 7D7A5540*.' four times. Then 'Runtime error 216 at 0299F6C4' * This number is not reproducible, it changes each time. E.g. I've also got 7DB17540. -- 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 17

[Bug 27228] New: Battlefield Play4Free: Crashing when running initial update/download
by wine-bugs＠winehq.org Nov. 12, 2014

Nov. 12, 2014

http://bugs.winehq.org/show_bug.cgi?id=27228 Summary: Battlefield Play4Free: Crashing when running initial update/download Product: Wine Version: unspecified Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: karlmk(a)hotmail.com Created an attachment (id=34796) --> (http://bugs.winehq.org/attachment.cgi?id=34796) Errors when running the updater from command line. How to reproduce this problem: 1. Download and install firefox 3.6.17 from mozilla.com 2. Go to battlefield.play4free.com 3. Log in 4. Press Play now 5. Install the requested plugin, and press restart. 6. The game (or actually the updater) starts, and shows you the EULA, but crashes. A little explanation on how this game works when launching. You go on the website and installs a plugin, this plugin basically contains an exe file called BP4FUpdater. When you press on the "Play Now" button online, this file gets called with a bunch of parameters. This exe will check that the game is up to date before launching it, and if this is the first time you run the game, it will download the game. If you want to try and launch the updater directly you can go into: C:\Users\<YourUserName>\AppData\Roaming\Mozilla\Firefox\Profiles\ceaeu01e.default\extensions\battlefieldplay4free(a)ea.com\plugins and run BP4FUpdater.exe -sessionId "<YourSessionKey>" -serverDeltaTime "0" -loggedIn "true" -showStaticAdImage "false" -lang "en" -ip "<YourIP>" -soldierName "<YourSoldierName>" -hostname "battlefield.play4free.com" The variables sessionId, ip and soldierName are you able to get from the webpage you get to when you press Play Now, inspect the source, and search for sessionId. Attatched are the errors I get when running the updater directly from the command line, with the correct parameters (as seen working on a vmware image). -- 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 5