Date: Sun, 17 Nov 2019 12:29:11 -0700 (MST) From: Subject: Re: [pmm2-U] PMMail 3.24 beta 1 On 2019-11-17, at 06:12:51, Neil Waldhauer wrote: > >On 11/16/19 10:08 pm, dougb007 at telus dot net wrote: >>On 2019-11-15, at 16:36:41, Neil Waldhauer wrote: >>>A beta build of PMMail for OS/2 version 3.24 is available on the >>FTP >>>site. >>> >>>ftp://pmdevpub:anyname%40anydomain at ftp.os2voice dot org/ >>> >>>PMMail is built with GCC 4.9.2 and requires libcx. To satisfy this >>>requirement, you can use Arca Noae Package Manager or yum. >>The package >>>to >>>install is named libcx. >>> >>>The filename of the beta version is pmmail-3-24-00-2373.wpi. This >>>version >>>is time-limited, and operation will degrade after the limit is >>reached. >>>To reset the limit, reinstall the release version. >>> >>>Please give feedback to the PMMail users list. >>Okay, I finally found a bit of time for this. So far, this is what I >>have >>found: >> >>PMMUTIL.EXE is not included. PMMUTIL.ICO is included. >>(PMMUTIL replaces the badly named Migration tool). >> >>Since PMMUTIL.EXE is not included, it cannot run for the update, >>and therefore fails to remove the obsolete files (such as >>DRCTL017.* which may be in ....\PMMail\bin). Not having the file >>present probably causes the failure to create the PMMail Utility icon >>too. >> >>DRCTL is another package that needs to be installed by ANPM >>(RPM/YUM). Note that there are probably many copies of >>DRCTL017.DLL on your system, which may need to be removed >>before installing from ANPM (RPM/YUM). You may also have older >>copies (like DRCTL016.DLL), which should be left for the programs >>that need them. The DRCTRL package should be installed BEFORE >>attempting to install, or update, PMMail. There should be only ONE >>copy of DRCTL017.DLL, and it should be in >> at unixroot/usr/lib/drctl017.dll. If you insist on managing that stuff >>without using RPM/YUM, it can be anywhere in your LIBPATH, but >>don't blame PMMail, when something doesn't get done properly. >> >>Some details need attention, but the program seems to work okay. >> >>More when I find more time... > >The gory details probably belong on the programmer's list, but the >details of the installer are to me a grey zone, part end-user and part >developer. So I'll leave this discussion here. Yes, the details should be in the programmers list, but it doesn't hurt to show users what is needed to build PMMail, every once in a while. >First, I have to say thanks to Doug for the helpful comments. > >I looked in trunk\PMMail\Makefile, and it still is trying to make >MigratePMM.exe. I thought I found, and changed those entries, but they may have got lost in the shuffle. >Is it just a simple name replacement MigratePMM.exe --> PMMUTIL.EXE? I >think not. Below that, there is an entry for MigratePMM.exe: ... that >builds MigratePMM.exe Yes, just change MigratePMM to PMMUTIL (all instances, not changing the extensions), and it should be okay. It is just a name change. I think the entry in the WIS, to build the program icon, is not correct, but that needs to be tested, with the proper files, before trying to change it. >I see you have PMMutil.RES in version control. It isn't really right to >have a binary in version control, but it isn't any worse than having >MigratePMM.RES in version control, so I'm OK with it for now. PMMUTIL.RES is DrDIALOG source code, which needs to be compiled to PMMUTIL.EXE, and moved to the \bin directory for install. It is all done in the make file. Other things, like BogoFilter.EXE, and STunnel.EXE are kept in version control, so we can just replace the files when they are updated. I suppose that we really should actually build those, but they are not "our" software. >I propose to change the Makefile by substituting PMMutil for MigratePMM. >I know you are busy, so I think that's all that would be needed to get >PMMutil.EXE into the WarpIN installer. I think that should be it. >As for adding DrCtl (note capitalization, it's important) I will add >that to the RPM/YUM installation instructions. As for cleaning up >whatever the user has, I don't want to automatically clean up what the >user has manually added. If PMMutil.Exe can clean that out of the old >BIN directory, that is OK. PMMUTIL will clean out the stuff that was installed by older versions of PMMail. Other occurrences are up to the user, but trying to install DrCtl will complain, if any instances are found anywhere in LIBPATH (the one that PMMail installed is not in LIBPATH, unless a user put it there). >I hope these two changes should address all the problems you listed. As >for users manually installing prerequisites, I intend to help them in >the future with a distribution that contains all prerequisites and does >not depend on RPM/YUM. Sorry, but PMMail depends on packages installed by RPM/YUM. Ideally, everybody would use that, and we could just do it by a command in the installer, but some people still refuse to use RPM/YUM, so it complicates what we need to do (and makes what THEY need to do much more difficult). If there was an easy way to a) tell if RPM/YUM is installed, and b) tell if the user is actually using it, we could automate the process for those who use it. Those who don't are on their own. It will never be done right, if they don't use RPM/YUM, there are just too many details to manage manually. DrCtl is a package that is required by PMMUTIL, and PMMUTIL is run by the installer, so it needs to be there first. I believe that there is also a problem where aspell.cnf is not properly set up by the program, or the installer. That should result in PMMail using the old PMMail 2.x spell checker, which is okay if that is what is wanted, but it needs to be set up to use the ASpell that is installed by RPM/YUM. I will note, that WarpIn has some new features, that might be helpful, but right now, I haven't had the time to figure out what it is capable of doing. RPM/YUM also has the wpi4rpm package, that is supposed to make entries in the WarpIn database, for packages that may be required by WarpIn installers, but are installed by RPM/YUM. Between the two of them, it should be possible to automate the dependencies. The problem is, that somebody needs to figure it out, and make it work, and the users need to have the proper packages installed. We could also use a couple of extra people to do proper testing, especially those who speak languages other than English. PMMail has not been translated, but users should be able to use it with mail of any language. While I am at it, I will ask if anybody is still trying to use PMMail with the old 16 bit TCP/IP stack? If not, we can get rid of another part of the build process (which hasn't worked for years anyway). Users do have the option to update to the 32 bit TCP/IP stack, and most have probably done that, years ago, for other reasons. They can also stay with older versions of PMMail, that still work (NOT recommended). >best regards, > >Neil -- **************************** From Doug Bissett's ArcaOS system dougb007 at telus dot net **************************** ... A shark is the only fish that can blink with both eyes. ----------- To unsubscribe yourself from this list, send the following message to MajorMajor at os2voice dot org unsubscribe PMMail2User end