November 2015 - Wine-Bugs - list.winehq.org

[Bug 39385] New: Make the VM descriptions visible
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=39385 Bug ID: 39385 Summary: Make the VM descriptions visible 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: --- Each VM has a long description of its hardware and software configuration. They are meant to help developers figure out what's special about a specific VM and how it may explain its results. The long descriptions can be found on the test.winehq.org site by looking at individual reports information. But they cannot be seen on the testbot.winehq.org site except by the administrator when editing the VM configuration. They should be visible as a tooltip/infotip in most places when the VM's name is displayed. -- 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 34256] New: Please add "See Also" support for NetBSD, FreeBSD, etc.
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

http://bugs.winehq.org/show_bug.cgi?id=34256 Bug #: 34256 Summary: Please add "See Also" support for NetBSD, FreeBSD, etc. Product: WineHQ Bugzilla Version: unspecified Platform: x86-64 URL: http://source.winehq.org/git/bugzilla.git/blob/HEAD:/B ugzilla/Bug.pm#l2854 OS/Version: Linux Status: NEW Keywords: download, source Severity: enhancement Priority: P2 Component: bugzilla-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk Classification: Unclassified Created attachment 45590 --> http://bugs.winehq.org/attachment.cgi?id=45590 Error screen See attached screenshot. Could someone with the relevant skills please add support for adding bug trackers for the following to the "See Also" link? FreeBSD (http://www.freebsd.org/support/bugreports.html) Linux (https://bugzilla.kernel.org/) Illumos/OpenIndiana (https://www.illumos.org/issues/) NetBSD (http://www.netbsd.org/support/query-pr.html) Solaris (http://bugs.sun.com/) OpenBSD has shut down their bug tracking system. *shrugs* http://www.openbsd.org/query-pr.html Not urgent, but useful. -- 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 39414] New: Add a partway job status
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=39414 Bug ID: 39414 Summary: Add a partway job status 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: --- If a task is completed the corresponding job's status is 'Running' even if none or the remaining tasks is actually Running. So one can sometimes end up with dozens of 'Running' jobs when only one or two among them actually has an active task. So the idea would be to reserve the 'Running' status to jobs for which one task is actually running. Jobs where some tasks but not all have completed would instead have the 'Partway' status (suggestions for another name welcome). Another issue is that when multiple jobs are in the 'Running' or 'Partway' state it's hard to know which ones have been modified the most recently because the 'Ended' field is not set. This is probably less important though and a waterfall like presentation would help (see bug 39413). -- 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 39413] New: Make it easier to monitor the TestBot activity
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=39413 Bug ID: 39413 Summary: Make it easier to monitor the TestBot activity 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: --- At the bottom of the main page there is a list of the VMs and their status. However the information there is incomplete: * When a VM is reverting there is no way to know for how long it has been reverting. * When a VM is running a task there is no link to the corresponding task. * There is no history of events so if someone reports that something strange happened there is no way to check(*). So it would be nice to have something like BuildBot's Waterfall display. http://buildbot.buildbot.net/waterfall (*) Actually one could check the WineTestBot log but that has its own problems and requires poring over lots of traces. See bug 39410. -- 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 32354] New: testbot: A crashing test is not detected
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

http://bugs.winehq.org/show_bug.cgi?id=32354 Bug #: 32354 Summary: testbot: A crashing test is not detected 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: wine.dev(a)web.de Classification: Unclassified A 64bit test crashed on all 64bit testbot machines, but the summary has "0" as "Number of failures". Test run for the broken patch: http://testbot.winehq.org/JobDetails.pl?Key=22963&log_301=1#k301 Later test: http://testbot.winehq.org/JobDetails.pl?Key=23106&log_302=1#k302 (I send a fix for the broken code in wine in some minutes) -- By by ... Detlef -- 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 10

[Bug 39441] New: The reverts keep getting slower
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=39441 Bug ID: 39441 Summary: The reverts keep getting slower 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: --- A revert that would take under 10 seconds right after creating the snapshot would take over 7 minutes 6 months later. So every few months this would cause the TestBot to become really sluggish and barely able to keep up with the patch influx. Restarting libvirt, rebooting the host, restoring the VM from backup or even transferring it to another host had no effect on the revert time. While the revert is taking place the QEmu process fully occupies one core, no disk I/O is performed and the VM is not running. The exact reason is not yet known exactly but it seems to have to do with the VM's timer devices, particularly the rtc one. To confuse matters further not all VMs are affected: only Windows 2000, XP, 2003, 2008 and 10 suffer from this. The other post Windows Vista are immune. Yet the guest is not active while the revert is taking place so it should not have an impact on it. Finally at WineConf 2015 it was discovered that the revert time of a live snapshot is simply proportional to the snapshot's age. This yielded a first workaround which is to refresh the live snapshots regularly. Further investigation showed that the common point between the impacted live snapshots is that they all have the following clock settings <clock offset='localtime'> <timer name='rtc' tickpolicy='delay'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> while the unaffected VMs have <clock offset='localtime'/> But switching from the former to the latter does not fix the affected VMs. Still this lead to a better fix which has now been put in place: setting track='guest' on the rtc timer. Regardless, something is wrong with the way QEmu handles timers and live snapshots so a bug was reported: https://bugs.launchpad.net/qemu/+bug/1505041 Maybe this will shed some light on what's really happening and what the correct timer settings are. -- 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 37104] New: Infinite revert loop
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=37104 Bug ID: 37104 Summary: Infinite revert loop 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 The current task scheduling algorithm can enter into an infinite revert loop while trying to prepare VMs for the next tasks. Assume the following settings: $MaxRevertingVMs = 2; $MaxRevertsWhileRunningVMs = 0; $MaxActiveVMs = 2; Then the following sequence can play out: | Steps VM | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 ----+-----+-----+-----+-----+-----+-----+-----+----- vm1 | rev | idl | off | off | rev | rev | rev | ... vm2 | rev | rev | rev | idl | off | off | rev | ... vm3 | off | off | rev | rev | rev | idl | off | ... The issue happens in steps 2, 4 and 6. The scheduler can shut down idle VMs to replace them with VMs that are more appropriate for the upcoming tasks. This is what happens in these steps: it decides the idle VM it just prepared is not what it wants after all, and thus shuts it down and prepares another one. The problem is it keeps changing its mind over and over and can never actually start a task because there is always a reverting VM and $MaxRevertsWhileRunningVMs = 0. Another prerequisite for this scenario to play out is probably to have multiple tasks have the exact same priority, so that their order is undefined. But regardless, the scheduler should probably not be shutting down an idle VM that has an actual 'pending' task. -- 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 39470] New: https://bugs.winehq.org/page.cgi?id=fields.html needs to be updated to include new statuses
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=39470 Bug ID: 39470 Summary: https://bugs.winehq.org/page.cgi?id=fields.html needs to be updated to include new statuses Product: WineHQ Bugzilla Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs(a)winehq.org Reporter: dimesio(a)earthlink.net Distribution: --- NEEDINFO and STAGED need to be added and UPSTREAM needs to be changed to NOTOURBUG. -- 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 39411] New: Provide a way to monitor VM revert times
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=39411 Bug ID: 39411 Summary: Provide a way to monitor VM revert times 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: --- It would be nice to have a graph of the VM revert times to verify that everything is working fine (or conversely to get a better sense that things are wrong and action is needed). Currently the way to do so is to ask Alexandre for the WineTestBot log, run a perl script on it to get a CSV, and import the CSV in a spreadsheet to graph the data. That's pretty cumbersome and obviously does not permit regular monitoring. Providing per-VM revert time graphs, maybe using something like RRDtool would be really nice. But then one could argue that revert times should just be low and stay that way and that then monitoring them may not be needed. -- 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 31784] New: Add support for VM snapshots
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

http://bugs.winehq.org/show_bug.cgi?id=31784 Bug #: 31784 Summary: Add support for VM snapshots 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 As we expand the number of configurations to test it seems wasteful to have to create and maintain a brand new VM just for them. In a lot of cases all we need is to slightly reconfigure a VM to add a CD image, add network interfaces or change the locale and run the test with these changes settings. That's where snapshots can be useful: take a snapshot for each configuration we need to test and then let the TestBot start the VM from the right snapshot. There is a catch though: while it's possible to run the tests in two VMs in parallel, for a given VM only one snapshot can be active at a time. There's two consequences: * TestBot must know about snapshot and not try to simultaneously run the tests in two snapshots belonging to the same VM. * If in the base configurations (those all Wine patches run on) we have a VM with ten snapshots, it means we will need to run the tests ten times *sequentially*. That VM is quickly going to become a bottleneck. So we should still limit the number of snapshots per VM, at least in the base configurations. -- 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