Re: [lmi] Adapting to wine-8

[Vadim Zeitlin]

On Mon, 23 Jan 2023 17:54:53 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

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

 FWIW Wine developers did quickly react to this bug and there is already a
merge request (≃ pull request) fixing it, so this message should disappear
after the next Wine update.

GC> So maybe it would be better, when running disconnected, to launch
GC> Xvfb early in the 'lmi_setup_*' scripts?

 Yes, I think it would be.

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

 I don't see how running Xvfb would obstruct that, it would just prevent
anybody else from using 99th X display, but there are probably few people
using it (and the DISPLAY value you export wouldn't affect anybody else).
So you could probably just leave it running, although you would have to
ignore any errors when trying to run it again -- or you could test if it's
not already running and only launch it in this case, e.g.

        export DISPLAY=:99
        if ! xset -d $DISPLAY -q >/dev/null 2>&1; then
                Xvfb $DISPLAY &
        fi

(the use of "-d" above is redundant but arguably makes things more clear).

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

 I don't have to deal with SIGHUP in CI script, so I'm not sure about the
interaction between nohup and xvfb-run, but I think it should work. And, in
any case, I definitely agree with the idea of launching Xvfb before doing
anything else to let Wine use it.
 
GC> > VZ> But the rest of the messages seems to be about some internal Wine 
stuff
GC> > VZ> that we don't really care about and so could be suppressed and I'll 
do it
GC> > VZ> just to clean things up a little.
GC> > 
GC> >  On further thought, perhaps it's better to leave them because WINEDEBUG
GC> > mechanism is too coarse. E.g. we're definitely not interested in the
GC> > messages such as
GC> > 
GC> > 03c4:fixme:shell:SHAutoComplete stub
GC> > 
GC> > because this just means that SHAutoComplete() is not implemented (which it
GC> > isn't), but I don't want to suppress all fixme messages from the shell
GC> > component just in case some more interesting/important ones appear in the
GC> > future.
GC> 
GC> Good point. That's an argument for filtering logs instead of using
GC> $WINEDEBUG too promiscuously. I need to give that more thought.

 Yes, I'm afraid filtering the logs is the only alternative, i.e. I'm all
but certain that Wine doesn't provide any finer-grained built-in log
filtering.

 Regards,
VZ

pgporgfydX3RJ.pgp
Description: PGP signature