Your weekly winetest update

[Francois Gouget]

On Thu, 1 Feb 2018, Zebediah Figura wrote:
[...]
> * user32:win, perhaps one of the most notorious offenders, has three
> consistent failures left, and possibly some more intermittent ones.
>   - Lines 3364-5 (test_SetForegroundWindow) and 9940-4
> (test_LockWindowUpdate) were determined by jwhite to be the fault of the
> hwndMain test window being minimized during the test. I further
> investigated and traced this down, surprisingly enough, to a bug in
> fvwm, which I've reported at [5]. The bug involves a lot of steps to
> trigger, notably, and we can (and, I think, should) work around it by
> modifying the test machine configuration: either by changing the focus
> mode from MouseFocus, or by removing the RaiseTransient or
> StackTransientParent style.
> [5] https://github.com/fvwmorg/fvwm/issues/51

I'm not sure what to do for this. Here's the fvwm configuration of the 
cw1 and cw2 machines:

$ cat ~/.fvwm/config 
Style * ClickToFocus
DesktopSize 1x1

The rest comes from the standard Debian configuration file: 
/usr/share/fvwm/default-config/config

So I think that means MouseFocus should not be an issue. RaiseTransient 
however seems to be controlled by StackTransientParent which the Debian 
configuration file sets as follows:

# Transient Windows (such as open file windows)
Style * DecorateTransient, StackTransientParent
Style * !FPGrabFocusTransient, FPReleaseFocusTransient

What setting do you recommend?


> Also along these lines: presumably setting up the testbot to run linux
> tests is going to require a fair amount of work, and that work is going
> to be implied to be François' responsibility. I'd just like to say that
> I'm willing to help as much as I can, though.
> 
> Okay, so, all that said, we have another problem. I've tried running
> winetest on my own machine recently, in the interest of rooting out some
> of the rarer failures, and I've found that the reports it generates are
> consistently about 1.7 MB long, which is of course over the 1.5 MB limit
> that test.winehq.org accepts. I did some sed'ing and came up with the
> worst offenders as being:

test.winehq.org actually gobles up surprising amounts of disk space.

On my test machine I have 977 reports using up 7.2GB. I estimate that 
test.winehq.org has 2100 reports (54 reports times 39 days), thus using 
around 16GB. 

Then there's the old reports that are no longer online but are still 
lurking in old-data. I have no idea why we even keep those. On my 
machine they use another 7.7GB so maybe that's another 16GB on 
test.winehq.org.

At least these estimates are quite a bit lower than those I came up with 
in april. I think we have fewer reports per day now (54 instead of 60), 
and my archives are much smaller too (but I don't remember if it's 
because I tweaked some local setting). There's more discussion on the 
whole test.winehq.org subject there: 
https://www.winehq.org/pipermail/wine-devel/2017-April/117162.html


Anyway, we might have to increase the limit at some point, but keeping 
the log sizes reasonable is important too. So I sent a patch that marks 
tests that output more than 32KB of traces as failed on test.winehq.org 
in order to push for a review / refactoring of those tests. If the patch 
is accepted I can send the same one for the TestBot so patches that 
bloat the traces are caught early.


-- 
Francois Gouget <fgouget at codeweavers.com>