Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Doug Bissett

Pages: 1 ... 104 105 [106] 107
Setup & Installation / Re: eCS 2.2 YUM/RPM question
« on: January 31, 2013, 09:45:59 pm »
So far with RPM/YUM there has been no definitive answer to how it is designed to work.  So far the answer is 'maybe' it will go on a non boot partition or 'maybe' it has to be on the boot partition.

There is no doubt that RPM/YUM can be on a volume, other than the boot volume. IMO, it should NOT be on a boot volume, but it CAN be. Whether the eCS installer will actually allow it to be put on a volume, other than the boot volume, is yet to be seen (if it doesn't allow it, it won't get installed until AFTER the main install, if I install it at all - which is unlikely, except on my test machine).

The only unknown is whether two boot systems can share the information, successfully. If it is done properly, there should be no problem. If it isn't done properly, it could be somewhat interesting, to say the least.

Setup & Installation / Re: eCS 2.2 YUM/RPM question
« on: January 31, 2013, 07:01:44 am »
I already have rpm/yum on an alternate drive. When the new eCS comes out and I would install it on a second boot partition with rpm/yum in the same place as it is now I expect there might be problems because files would get overwritten and the database will get messed up. So I intend -not- to install rpm/yum but simply copy and paste the appropriate lines from the old config.sys to the new one.
And that appears to be the big problem - multiple OS/2 eCS boot partitions on the same machine using common applications installed on a partition that can be used by all boot versions.

It has been NO PROBLEM, for me, but I haven't tried it with RPM/YUM. I share almost everything, on a common drive, between boot partitions. Some of them are (in no particular order):
OpenOffice 3.2
Electronic Teller
Lotus Smartsuite
PMView Pro
Photo>Graphics Pro
GenealogyJ (JAVA)
APC UPS monitor
and  few more that I don't use much.

Basically, most programs can be shared between boot systems, with no trouble. Doing it that way makes it a LOT easier when the time comes to install a new version of eCS. Generally, you do need to re-install the program, over top of the old, using the new boot system. Sometimes, simply creating icons is enough. WarpIN makes it very easy to just run through your collection of installers, to get it done. The best programs store all of there configuration stuff in their own directory, so it can be used by any boot system. Not too far behind, are those that store config stuff in the %HOME% directory (which also needs to be on the common drive), although I find that that gets badly cluttered. The worst programs, are those that insist on storing configuration stuff on the boot drive, especially when they put it in the system INI files. Even that is not a real problem, it just means that you need to be more careful when installing the programs.

I suspect that RPM/YUM will keep all of the configuration stuff in it's own directory structure, but I am not sure how easy it will be to synchronize it between two boot systems.

Setup & Installation / Re: eCS 2.2 YUM/RPM question
« on: January 30, 2013, 06:20:39 pm »
If I want to install it on another Drive this drive has to be already created and formatted before the "real" installation starts, otherwise I will not be able to install ODIN and so on...

True, but that is very easy to do. In most cases, on a re-install, the alternate drive will already be set up, and formatted. If it is s new install, and the drive isn't already set up, you can do that when you set up the drive during install. Create all of the volumes, then the install drive is formatted. At that time, there is the option to format the rest of your drives (JFS, HPFS, etc. Not FAT32 or NTFS). Once they are formatted, you are free to use them.

Personally, I take the opportunity to select the alternate drive to contain the %HOME% and %PROGRAMS% directories too. Hopefully, the updated installer will also allow a user to specify the %UNIXROOT% directory at the same time, even if a user chooses not to use RPM/YUM. If that is done, and %UNIXROOT% is placed on an alternate drive, a user should be able to install RPM/YUM some time in the future, without messing up too many things. One of the reasons that I do that, is that I can share those directories between multiple boot drives. I am not sure what implications that would have with RPM/YUM (could be a horror show, if they don't do things properly), but everything else that I have tried works fine.

Applications / Re: Qpdf
« on: January 27, 2013, 01:45:19 am »
It looks like the FIRST time I open QPDFView, it puts entries into %HOME%, as I expect ("adds" entries would be more accurate). The second time I open it, it puts the same entries into the root of my boot drive. My boot drive is M:, and QPDFView is in W:\APPS\QPDFVIEW. The PDF file is in W:\DOWNLOAD. The working directory, in the program icon, is set to W:\APPS\QPDFVIEW. CUPS is on M:.

I will say that when it works, QPDFView is pretty good, although I do have a discrepancy about what the real Acrobat Reader , in windows, does, and what QPDFView does, when editing fields in a PDF file. I need to figure that out, and report it somewhere.

Applications / Re: Qpdf
« on: January 26, 2013, 12:10:34 am »
I found another problem with QPDFView. It has put two directories in the root of my boot drive: .config and .local. Normally, those things follow the %HOME% environment variable, which certainly does not point to the root of my boot drive.

Applications / Re: Qpdf
« on: January 25, 2013, 10:45:53 pm »
which cups do you have? you need very latest cups.dll from Paul, as older ones did not work with Qt Apps.

I thought I had the latest, but apparently the latest is only available in the ZIP file download.

11-03-12 10:41p       913,935    124 a---  cups.dll

(MM-DD-YY). So, now I can print ONCE, after a boot. I can use other apps to print through CUPS, but QPDFView only prints once, then it complains that is could not print. On the down side, if I print using CUPS (ANY program), I end up with one (of 4) of my CPUs stuck at 99.9%, for about 10 minutes, after the print is finished. Then, that stops. While it is stuck, I have a LOT of trouble doing other things. After it stops, everything seems to be normal again. I can find no indication of what is hogging CPU time. TOP doesn't show it, only the Pulse widget shows it.

Applications / Re: Qpdf
« on: January 25, 2013, 12:21:00 am »
cups.dll is used to support printing as it provides the cient side api's to talk to a cups server.

Hmmm. That might explain some of the odd occurrences that I see when trying to print using CUPS. I have this:
 6-10-12  6:57p       920,419    124 a---  cups.dll
        1 file(s)     920,419 bytes used

Directory of M:\cups\sbin

 8-31-11  6:19p       869,291      0 a---  cups.dll
        1 file(s)     869,291 bytes used

Which one is right? Neither one of them is in LibPath. Perhaps that explains why I can't print from QPDFView. AHA!, yes it does. I tried BeginLibPath to M:\cups\lib and it no longer hangs. It still doesn't print. It pops up a message box that says "Could not print <the file name>". Not extremely helpful, but better than a hang. Now, to try more things...

Applications / Re: Qpdf
« on: January 24, 2013, 09:28:39 pm »
If I try to open a pdf from another directory than that where qpdfview is installed it complains about popqt44.dll not found. So it seems to me that qpdfview doesn't look in it's own directory for its dlls. Is that correct and does it have to be placed in the path or at least do the dlls have to be moved to a directory in the path?

Two things should help. One is that the Working Directory (in the program icon properties) should be the directory where QPDFView is installed. The other is that you should have ".;" (dot semi-colon, without the quotes) in the LibPath statement, in CONFIG.SYS. That is usually close to the beginning of that line. Having the dot entry tells the system to look in the current path (the Working directory) for DLLs. Of course, if you try to use QPDFView from the command line, you need to put the install directory in LibPath, or put the DLLs in a directory that is in the LibPath.

Applications / Re: Qpdf
« on: January 24, 2013, 06:07:56 pm »
I installed QPDFView (after figuring out that there is bad information about JPEG, which should be LIBJPEG). It seems to display okay, but trying to print locks the program, and the desktop. I can CAD to CADH, and kill it, but something is wrong. Yes, I do have CUPS 1.4.8 installed, but it doesn't work very well with my printer (Canon i960, using the BJC-8200 CUPS driver, which is recommended for this printer. It works far better with the OMNI driver for the Canon i950).

On the bright side, I no longer have a mangled display, when scrolling a few lines at a time (at least I haven't seen such a thing, yet). I was never able to get Lucide to edit a PDF file, and QPDFView does do that, although I am not sure that the font that it uses will be acceptable to the government bureaucrats for the form that I want to edit. I will need to compare what it does to Acrobat reader in windows.

I am not sure why I would want plugins. All I ever use Lucide, or now QPDFView, for, is to read, and print, PDF files (and now, possibly, to edit them, as allowed). Since QPDFView won't print (for me), I guess I need to keep Lucide for that job.

The big problem I find with qpdfview is that if I try and open a pdf on another partition (qpdfview installed in e:\qt4-apps, want to open pdf in f:\download) it locks the machine solid and I have to power off and then on again.

I tried that. It works okay, for me. That may indicate that something in printer support is causing a problem. AH!. My CUPS printer driver is installed on my boot drive (poor choice of location, but not worth moving it now). The test, that hung, that I did was on my data drive, where I installed QPDFView. I copied the test PDF to my boot drive, and it opens with no trouble. It still hangs when I click Print. KLibc Pathrewriters might be needed. I will need to find the time to experiment with that stuff.

Comments, Suggestions & Questions / Re: Cruelty in OS2World
« on: January 17, 2013, 05:40:43 pm »
When I log in, there is an option to stay logged in "forever". I always click on that, and I don't get bumped off.

Setup & Installation / Re: Migration problems
« on: January 15, 2013, 01:45:30 am »
You may want to consider removing a couple of lines in your CONFIG.SYS:

According to the ConfigTool database:

is for warp 3 only, and should be set in the warp4 (and up) settings, not in CONFIG.SYS.

is also for warp3 only.

You could also try adding the line:
near the top of your CONFIG.SYS

Programming / Re: Have questions about porting software to eCS?
« on: January 05, 2013, 04:11:55 am »
Thanks to Paul, I updated to his latest build environment, and applied the DIFF to the WGET 1.14 source (not sure that I did it right, but it works), and now I can build WGET 1.11.1 and WGET 1.14.  :-*

Unfortunately, I broke building PMMail when I did the update. I obviously deleted something that was added to something that got replaced.  :(

Oh well, you win some, and you lose some. Now, to sort out the PMMail build problem.

Well, it took a lot of time, but I got PMMail to build, and I can build WGET 1.14, using the DIFF described earlier by Paul.

I was going to restart a thread about building WGET 1.14, but it seems that all you need is Paul's latest build package, download the WGET package of choice from:

(I took the 1.14 tar.gz package), unzip it, and follow Paul's instructions.

Once you get that far, you know that the build environment is basically working, so you can then progress to other projects. It is probably best to pick something relatively simple, that has been done before, so it will be easier to get help when something doesn't go as expected, before going on to building more advanced things (like VirtualBox).   ;D

Have fun... ;)

Programming / Re: Have questions about porting software to eCS?
« on: December 31, 2012, 05:45:04 am »
Thanks to Paul, I updated to his latest build environment, and applied the DIFF to the WGET 1.14 source (not sure that I did it right, but it works), and now I can build WGET 1.11.1 and WGET 1.14.  :-*

Unfortunately, I broke building PMMail when I did the update. I obviously deleted something that was added to something that got replaced.  :(

Oh well, you win some, and you lose some. Now, to sort out the PMMail build problem.

Programming / Re: Have questions about porting software to eCS?
« on: December 29, 2012, 04:55:34 pm »
Fairly trivial.

For you maybe.  :)

Anyway, now I need to find the time to figure out what you just said, and get this thing to build.


Programming / Re: Have questions about porting software to eCS?
« on: December 28, 2012, 08:14:22 pm »
FWIW, I downloaded the wget 1.14 source this evening and have run configure.  Will see what's required for me to get it building and post back here

Don't waste too much time on it. I can't get wget 1.11.1 to build either. There is something in my configuration that is wrong, and I won't have time to try to figure it out, until next year.

Pages: 1 ... 104 105 [106] 107