August 2014 - Wine-bugs - list.winehq.org

[Bug 37145] New: Can not submit confirmation string on the website
by wine-bugs＠winehq.org 13 Nov '14

13 Nov '14

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.

1 4

[Bug 32856] New: Add a VM running the tests from a non c: drive
by wine-bugs＠winehq.org 13 Nov '14

13 Nov '14

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.

1 4

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

13 Nov '14

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 13 Nov '14

13 Nov '14

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 13 Nov '14

13 Nov '14

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 13 Nov '14

13 Nov '14

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 13 Nov '14

13 Nov '14

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 13 Nov '14

13 Nov '14

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 13 Nov '14

13 Nov '14

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 13 Nov '14

13 Nov '14

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