Re: [lmi] Adapting to wine-8

[Greg Chicares]

On 1/23/23 15:17, Vadim Zeitlin wrote:
> On Mon, 23 Jan 2023 14:13:27 +0100 I wrote:
> 
> Me>  I'm going to look into NtUserScrollWindowEx message because it seems
> Me> suspicious to me that we use ScrollWindow() with some flags unusual enough
> Me> to be unsupported by Wine, so I'd like to make sure there is no bug in wx
> Me> here.
> 
>  I can now confirm that there is no bug in wx, but I think there is a bug
> in Wine as a relatively recent refactoring results in ScrollWindow()
> function calling NtUserScrollWindowEx() with invalid flags, see
> https://bugs.winehq.org/show_bug.cgi?id=54357

Great, thanks for the update.

> VZ> And nodrv_CreateWindow could probably be avoided by just launching
> VZ> Xvfb earlier, so I think I might do this just because it doesn't cost 
> much.
> 
>  And I can also confirm this, i.e. these warnings don't appear in the CI
> logs any longer after moving the step launching Xvfb up.

So maybe it would be better, when running disconnected, to launch
Xvfb early in the 'lmi_setup_*' scripts? That sounds like a tidy
way to suppress a significant subset of the nuisance messages.

I suppose I could just start xvfb and background it:
  Xvfb :99 &
  export DISPLAY=:99
before starting my batch job. But then I'd have to remember to
kill it, eventually. Even though we never seem to have been able
to get an X GUI on our corporate laptops, maybe some administrator
is running GUI tools, and would be unhappy if I obstructed that.

Alternatively, maybe instead of
  $rm nohup.out; nohup /wherever/lmi/gwc/redhat_rebuild.sh & disown; exit
I should try
  $rm nohup.out; nohup xvfb-run /wherever/lmi/gwc/redhat_rebuild.sh & disown; 
exit
                       ^^^^^^^^
I could experiment with that myself, but it sounds like you may
already be doing this in CI, so I figure I should ask you first.

> VZ> But the rest of the messages seems to be about some internal Wine stuff
> VZ> that we don't really care about and so could be suppressed and I'll do it
> VZ> just to clean things up a little.
> 
>  On further thought, perhaps it's better to leave them because WINEDEBUG
> mechanism is too coarse. E.g. we're definitely not interested in the
> messages such as
> 
> 03c4:fixme:shell:SHAutoComplete stub
> 
> because this just means that SHAutoComplete() is not implemented (which it
> isn't), but I don't want to suppress all fixme messages from the shell
> component just in case some more interesting/important ones appear in the
> future.

Good point. That's an argument for filtering logs instead of using
$WINEDEBUG too promiscuously. I need to give that more thought.