[Bug 48354] New: Some patches may require forcing a wineprefix update

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

Bug ID: 48354
           Summary: Some patches may require forcing a wineprefix update
           Product: Wine-Testbot
           Version: unspecified
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

The TestBot updates the wineprefixes when it updates its base Wine source from
the daily Wine commits. The rest of the time it lets Wine deal with updating
the wineprefix is necessary. Furthermore Wine only updates the wineprefix when
wine.inf changes, which is the case for every Wine release.

The problem is that the wineprefix should also be updated when a patchset adds
a WINE_REGISTRY resource to an existing dll. Failing to do so may cause the
patchset tests to fail because the wineprefix is out of date.

See:
https://www.winehq.org/pipermail/wine-devel/2019-December/156914.html

Wineprefix updates are relatively slow compared to the execution time of most
tests (about 30s vs. < 1s) so it would be good not to have to do that for every
task. An alternative would be to force a wineprefix update when a task has
failures and gets rerun as a result (pass an option to the relevant VM-side
scripts).

[Bug 48354] Some patches may require forcing a wineprefix update

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

Jacek Caban  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Jacek Caban  ---
(In reply to François Gouget from comment #0)
> Wineprefix updates are relatively slow compared to the execution time of
> most tests (about 30s vs. < 1s)

It doesn't need to be so slow. It takes about 4s for me. I guess you're not
using shared mono and gecko installations. It's probably worth trying it and
see  how of the differences it makes. Also, I still need to recheck that after
your comment in bug 48052, but my impression was that Wine VMs run on single
core or at least that's what Wine reports.

[Bug 48354] Some patches may require forcing a wineprefix update

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

--- Comment #2 from François Gouget  ---
The TestBot downloads the latest Gecko and Mono installers and stores them in
siblings of the Wine build tree [1]. This ensures they don't need to be
redownloaded for each wineprefix creation. Is that what you had in mind for the
"shared mono and gecko installations"?

Also the actual wineprefix creation times are more between 13 and 28 seconds.
They can be seen in the log of the Reconfig tasks [2]. Outside QEmu things are
faster.

[1]
https://source.winehq.org/git/tools.git/blob/HEAD:/testbot/lib/Build/Utils.p...
[2] https://testbot.winehq.org/JobDetails.pl?Key=62613&f101=log#k101

[Bug 48354] Some patches may require forcing a wineprefix update

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

--- Comment #3 from Jacek Caban  ---
TestBot uses MSI files, which requires those MSI files to be processed and
installed into Wine prefix on prefix update. Support for that has always been
present for a long time and is still supported. However, we now allow Mono and
Gecko to be installed globally. Wine can use the global instead of per-prefix
installation, so those installation steps are skipped during prefix creation.
To use that, you'd need to extract archives [1], [2] and [3] into the same
place as you'd previously put MSI files.

[1] http://dl.winehq.org/wine/wine-mono/4.9.4/wine-mono-bin-4.9.4.tar.gz
[2] http://dl.winehq.org/wine/wine-gecko/2.47.1/wine-gecko-2.47.1-x86.tar.bz2
[3]
http://dl.winehq.org/wine/wine-gecko/2.47.1/wine-gecko-2.47.1-x86_64.tar.bz2

[Bug 48354] Some patches may require forcing a wineprefix update

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

François Gouget  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |48652

[Bug 48354] Some patches may require forcing a wineprefix update

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

Olivier F. R. Dierick  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #4 from Olivier F. R. Dierick  ---
(In reply to Jacek Caban from comment #3)
> TestBot uses MSI files, which requires those MSI files to be processed and
> installed into Wine prefix on prefix update. Support for that has always
> been present for a long time and is still supported. However, we now allow
> Mono and Gecko to be installed globally. Wine can use the global instead of
> per-prefix installation, so those installation steps are skipped during
> prefix creation. To use that, you'd need to extract archives [1], [2] and
> [3] into the same place as you'd previously put MSI files.
>
> [1] http://dl.winehq.org/wine/wine-mono/4.9.4/wine-mono-bin-4.9.4.tar.gz
> [2] http://dl.winehq.org/wine/wine-gecko/2.47.1/wine-gecko-2.47.1-x86.tar.bz2
> [3]
> http://dl.winehq.org/wine/wine-gecko/2.47.1/wine-gecko-2.47.1-x86_64.tar.bz2

Hello,

Installing shared versions of Mono & Gecko is currently not automatic.

For MSI files, wine just prompts the user and that prompt can be automatically
approved. There is currently no switch/environment setting to tell wine to
install the shared mono/gecko when that prompt pops up (not that I know of).

How can the Testbot detect mono & gecko version changes and install the shared
version?

Also, for me, updating prefixes can take from 5s up to 1m30s depending of
bitness (64 bits takes more time that 32 bits), wine branch (staging takes
longer than plain wine) and prefix contents, while I'm always using shared
mono/gecko installs.

Regards.

[Bug 48354] Some patches may require forcing a wineprefix update

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

--- Comment #5 from François Gouget  ---
Thatś okay. The TestBot being automated it cannot wait for the user to answer
the dialog prompt to install Gecko/Mono. So it has code to prefetch the msi
files in the place expected by Wine so the WinePrefix is entirely automatic.

https://source.winehq.org/git/tools.git/blob/HEAD:/testbot/lib/Build/Utils.p...

So what this bug is about is updating that code to work with shared installs.

[Bug 48354] Some patches may require forcing a wineprefix update

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

--- Comment #6 from Olivier F. R. Dierick  ---
Hello,

I was thinking more about something that everyone could benefit from, something
like what I suggested in comment #1 in bug 47316.

If there was some way to tell Wine to bypass the mono/gecko prompt and select
MSI or shared install without user interaction, wouldn't that simplify that
operation for the TestBot too?

Regards.

[Bug 48354] Some patches may require forcing a wineprefix update

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

François Gouget  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major

[Bug 48354] Use shared Gecko and Mono installs

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

François Gouget  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Some patches may require    |Use shared Gecko and Mono
                   |forcing a wineprefix update |installs

--- Comment #7 from François Gouget  ---
This bug has become almost entirely about shared Gecko and Mono installs so I'm
renaming it and moving the initial issue to a bug 48671.

[Bug 48354] Use shared Gecko and Mono installs

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

--- Comment #8 from François Gouget  ---
*** Bug 48652 has been marked as a duplicate of this bug. ***

[Bug 48354] Use shared Gecko and Mono installs

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354
Bug 48354 depends on bug 48652, which changed state.

Bug 48652 Summary: Use shared Gecko and Mono installs
https://bugs.winehq.org/show_bug.cgi?id=48652

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

[Bug 48354] Use shared Gecko and Mono installs

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

François Gouget  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from François Gouget  ---
This is fixed:

commit 81386ee720fffa9c55e52e9ce405e0ae0395ba7d
Author: Francois Gouget 
Date:   Thu Apr 23 15:04:27 2020 +0200

testbot/build: Add support for shared Gecko and Mono installs.

This adds the _UpdateSharedAddOn() method and only calls
    _UpdateMSIAddOn() as a fallback.
    This also updates _IsAddOnBad() to check for the presence of the shared
    install so the addon is not updated if it is present in either the
    shared install or MSI form. _IsAddOnBad() also stores the information
    needed to locate and update the addon for use by the update methods.

Signed-off-by: Francois Gouget 
    Signed-off-by: Alexandre Julliard

[Bug 48354] Use shared Gecko and Mono installs

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48354

François Gouget  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #10 from François Gouget  ---
Closing.