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.
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.
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.
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.org1.pool.ntp.org2.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.
https://bugs.winehq.org/show_bug.cgi?id=3766
Bruno Jesus <00cpxxx(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Fixed by SHA1| |21204f579e508872ab6e39282bb
| |801fb0219b65d
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #28 from Bruno Jesus <00cpxxx(a)gmail.com> ---
The original problem in this bug was fixed long ago by Dmitry, the bug then
morphed into something else. If this is still an issue in wine 1.7.30 or later
please open a new bug.
--
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.