WPI "lib" package still refuses to load w/o XWorkplace

[jh.stil]

Today downloaded Qt packages and GCC. Gcc installs w/o problem.
Despite statement that WPI is improved so XWorkplace and or XCenter are no longer needed, the Lib package refuses to install, complains about absence of XWorkplace and cancels.

OS: eCS 1.2R USeng
CPU: AMD SlotA 700 Mhz

Note: I am not familiar with this ticket system so I may not be reporting this at the right spot or in the proper way, in which case I apologize. Nevertheless wanted to let you know.

Jaap Stil

[Dmitry A. Kuminov]

Thank you for the report! The problem is known to us. The WarpIn? installer has limited functionality when it comes to complex requirements such as detecting the presence of other packages and changing the installer's behavior based on that information. In order to overcome the limitation, we attempted to access the WarpIn? database (DATABAS_?.INI files) directly, but apparently it works only on some systems. On systems where it doesn't work, this is explained by the fact that DATABAS_?.INI files are locked for everything (even for reading) while the WPI installation is being run, so that the REXX script in the WPI archive fails to open these files and as a result cannot properly detect the XWorkplace installation.

You can check if your case is the same or not by doing the following:

1. Download the attached test.wpi archive.
2. Install it.
3. Attach X:\test-wpi.log (where X is your boot drive) to this ticket.

[Dmitry A. Kuminov]

It turned out to be the WarpIn? version. WarpIn? 1.0.17 and eariler works, while the later versions don't. Here is the relevant WarpIn? bug: ​http://xtracker.xworkplace.org/index.php?bug=1155.

The bug should be fixed in WarpIn? 1.0.20. Until then we will move the Extended SysTray? plugin out from the main WPI to a separate WPI archive which is also logically correct because this plugin has nothing to do with Qt (doesn't depend on it in any way) and logically belongs to XWP where it will probably move soon.

[jh.stil]

Replying to dmik:

It turned out to be the WarpIn? version. WarpIn? 1.0.17 and eariler works, while the later versions don't. Here is the relevant WarpIn? bug: ​http://xtracker.xworkplace.org/index.php?bug=1155.

The bug should be fixed in WarpIn? 1.0.20. Until then we will move the Extended SysTray? plugin out from the main WPI to a separate WPI archive which is also logically correct because this plugin has nothing to do with Qt (doesn't depend on it in any way) and logically belongs to XWP where it will probably move soon.

[jh.stil]

Warpin version used was 1.0.19.

Tried to install test.wpi but installation fails for the same reason. Warpin error "Ulrich Möller\XWorkplace\Kernel\0\9\9\0" not present.Installation of "test.wpi exits. Do I need to reset warpin to older version ?

[Dmitry A. Kuminov]

Test.wpi is intended to log the activity and prove the failure. But I already know the exact reason anyway so it's no longer necessary to test it.

Regarding WarpIn?, if you downgrade to version 1.0.17,or an older version, the original noxwpdep WPI will work. Otherwise you will have to wait for the next release of Qt for OS/2 (within the next few days).

[jh.stil]

Have upgraded (in ECs 1.2R USEngl.) XWorkplace to v 1.0.8. After that the Qt WPI packages installed without protest.

jh.stil.

Replying to dmik:

Test.wpi is intended to log the activity and prove the failure. But I already know the exact reason anyway so it's no longer necessary to test it.

Regarding WarpIn?, if you downgrade to version 1.0.17,or an older version, the original noxwpdep WPI will work. Otherwise you will have to wait for the next release of Qt for OS/2 (within the next few days).

[Dmitry A. Kuminov]

In r737, I added creation of the separate "noxwpdep" WPI. Note htat when WarpIn? 1.0.20 is released, we should consider rolling back r737 as well as r736 and add VERSION="1.0.20" to the <WARPIN> header in scripts since the original solutions are more convenient than the introduced workarounds.

I created #155 to track this down and closing this one.