Messages

1

Applications / Re: Java applications

« on: October 25, 2022, 02:53:16 pm »

Hi Joop, I for one was sorry to see your site disappear. It was a useful resource for finding Java applications to run on eCS/ArcaOS. I checked it occasionally and I also thought your recommendations on how to make each program run (if it was possible) to be very useful.

Best regards, Thomas H.

2

Setup & Installation / Re: YUM update qt5-qtbase-common fails

« on: October 14, 2021, 12:22:27 am »

Thank you, that worked!
yum install os2-base dbus-libs
made the update of qt5-qtbase-common function again.

Aside from asking in the forum, is there some way I could have diagnosed this problem myself?

3

Setup & Installation / YUM update qt5-qtbase-common fails

« on: October 13, 2021, 10:57:58 am »

Hi everybody!
I recently ran into a problem while updating via YUM. 'yum update' results in the message

Code: [Select]

---> Package qt5-qtbase-common.noarch 0:5.13.1-1.oc00 will be updated
--> Processing Dependency: qt5-qtbase-common = 5.13.1-1.oc00 for package: qt5-qtbase-5.13.1-1.oc00.i686
---> Package qt5-qtbase-common.noarch 0:5.15.2-1.oc00 will be an update
--> Processing Dependency: qt5-qtbase = 5.15.2-1.oc00 for package: qt5-qtbase-common-5.15.2-1.oc00.noarch
--> Finished Dependency Resolution
Error: Package: qt5-qtbase-5.13.1-1.oc00.i686 (installed)
           Requires: qt5-qtbase-common = 5.13.1-1.oc00
           Removing: qt5-qtbase-common-5.13.1-1.oc00.noarch (installed)
               qt5-qtbase-common = 5.13.1-1.oc00
           Updated By: qt5-qtbase-common-5.15.2-1.oc00.noarch (netlabs-rel)
               qt5-qtbase-common = 5.15.2-1.oc00
           Available: qt5-qtbase-common-5.11.0-1.oc00.noarch (netlabs-rel)
               qt5-qtbase-common = 5.11.0-1.oc00
Error: Package: qt5-qtbase-common-5.15.2-1.oc00.noarch (netlabs-rel)
           Requires: qt5-qtbase = 5.15.2-1.oc00
           Installed: qt5-qtbase-5.13.1-1.oc00.i686 (installed)
               qt5-qtbase = 5.13.1-1.oc00
           Available: qt5-qtbase-5.11.0-1.oc00.i686 (netlabs-rel)
               qt5-qtbase = 5.11.0-1.oc00
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

I tried 'yum update --skip-broken'. It allows updating the other packages but not fixing the actual problem.
I ran 'rpm -Va --nofiles --nodigest' but that didn't fix the problem either.
I also tried running 'package-cleanup', which I had installed previously:

Code: [Select]

python f:\usr\bin\package-cleanup --problems
No problems found

python f:\usr\bin\package-cleanup --orphans
brlaser-6.0.0-0.i686
heimdal-7.7.0-3.oc00.i686
heimdal-libs-7.7.0-3.oc00.i686
samba-client-4.11.5-0.oc00.i686

python f:\usr\bin\package-cleanup --dupes
(No output, i.e. no duplicates found)

There were a few orphaned packages, but that was all. Does anyone have an idea how to solve this?

Best regards, Thomas Hellsén

4

Applications / Re: Cannot run BiblioteQ due to missing "YAZ5"

« on: August 01, 2020, 09:29:03 pm »

Thank you ivan and Dave, "yaz" could be installed from netlabs-exp (which I have now disabled again) and now BiblioteQ starts. I could create an SQLite database. Thank you TeLLie for porting the application. Now I can hopefully build my media catalog!

/Thomas

5

Applications / Re: Cannot run BiblioteQ due to missing "YAZ5"

« on: July 30, 2020, 11:06:00 pm »

Hi TeLLie, I tried those (and some variants, such as yaz*).
yum list "yaz"  --> Error: No matching packages to list
yum install "yaz5"  --> No package yaz5 available. Nothing to do.

Am I missing a repository? "yum repolist" returns only
netlabs-rel              Netlabs Stable Repository 00 - i386              6´┐¢539
repolist: 6´┐¢539

/Thomas

6

Applications / Cannot run BiblioteQ due to missing "YAZ5"

« on: July 30, 2020, 03:41:11 pm »

Hi!
I installed BiblioteQ, a Qt application from ftp.netlabs.org/pub/qtapps/, but I can't seem to run it. When I try to start it, I get the message
SYS0002: The system cannot find the file specified. "YAZ5"
True enough, the readme.os2 file specifies to install "yaz" with the command "yum install yaz", but YUM claims not to know anything about this package. "yum provides yaz*" gives "No matches found".

I get the same result with BiblioteQ v. 2019.03.15 and BiblioteQ v. 2018.07.04. Obviously I'm missing something here. Does anyone know how to get BiblioteQ to run?

Best regards, Thomas Hellsén

7

Applications / Re: Printing problems with GSView 5.0 and Ghostscript 9.15

« on: January 05, 2015, 04:44:34 pm »

Hi Paul,
My experiences parallel the ones in ticket 627 pretty exactly, except I never tried gs 9.14 so wasn't affected by the cups17.dll missing. When I tested gs 9.15 (gsos2.exe) by itself, it complained about gcc491 missing. This was easily fixed by downloading your gcc 4.9.1 and extracting the gcc491.dll to a directory in the LIBPATH.

The discussion in ticket 627 contains two for me useful tips, thanks for the pointer:
a) Print to file using ps2write.
b) Printing works with gs 9.04.
With 9.04, the message "Could not open the file \\spool\E312PS" is still there but apparently does not affect printing. The spooler is active (E:\OS2\PMSPOOL.EXE) so I suppose that's not the problem. The double backslash suggests that \\SPOOL is some form of system device but I don't know enough about those things to have any intelligent guesses as to what Ghostscript wants.

Best regards

8

Applications / Re: Printing problems with GSView 5.0 and Ghostscript 9.15

« on: January 05, 2015, 04:42:39 pm »

Hi Ivan,
1) Yes, printing from other applications works pretty well except for the usual trouble with the Lexmark E312 drivers, namely that printing to E312 PS from modern applications like OpenOffice and Seamonkey does not work while printing to E312 PCL works and some PDF files won't print correctly using Lucide (this is the reason I ran into the GSView problems, I usually use Lucide for PDF). Printing from "old" applications such as Clearlook, Mesa2 and StarOffice 5.1 works well. These are issues I've learned to work around.
2) Yes, as per Paul's instructions I've changed all instances of "pswrite" to "ps2write". I also changed one of the first lines in the file, namely
GhostscriptEXE=D:\APPS\GS\gs7.04\bin\gsos2.exe
to read
GhostscriptEXE=D:\APPS\GS\gs9.15\bin\gsos2.exe
The first appearance of the line is directly from GSView 5.0 install, even though I have no gs 7.04 on my system. Changing the line does not seem to produce any effect, and I have wondered what its purpose is.
3) Well they read as the "pswrite" entries before them since I only changed "pswrite" to "ps2write".
4) Yes, the directories in \var\SPOOL\ are there for each printer.

/Thomas

9

Applications / Printing problems with GSView 5.0 and Ghostscript 9.15

« on: January 05, 2015, 12:23:21 am »

Hi all,
I'm having problems with printing in GSView 5.0. I have Ghostscript 8.63 and 9.15 installed and they can both be run standalone, though I haven't tried printing directly from them. If I configure GSView for gs 9.15 I can load and display a PDF file, but when I try to print, I get the following error message in the popup "GSView Print" box:

GPL Ghostscript 9.15 (2014-09-22)
Copyright (C) 2014 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Unknown device: pswrite
Unrecoverable error: syntaxerror in --nostringval--
Operand stack:
    defaultdevice
Unrecoverable error: undefined in .uninstallpagedevice
Operand stack:
    defaultdevice
gsapi_exit returns 0
DosFreeModule returns 12

Now I think I have followed Paul's instructions in the readme.os2 file about configuring GSView:
In GSView Advanced configuration, I have set the include path to

D:\APPS\GS\gs9.15\lib;D:\APPS\GS\gs9.15\Resource\init;D:\APPS\GS\gs9.15\Resource\font;D:\APPS\GS\fonts;E:\PSFONTS;E:\TTFONTS;

where D:\APPS\gs is the Ghostscript & GSView common directory. Also, in E:\OS2\gvpm.ini I have changed all occurrences of the device "pswrite" to "ps2write". This does not seem to help, since the "pswrite" device is still called, as seen from the error message above. This is when I select the tick box "Postscript printer" when printing. It would seem like the "pswrite" device is hardcoded into GSView.
If I instead leave the "Postscript printer" box unticked and manually select the "ps2write" device and try to print, I get the following error message in the printing status box:

GPL Ghostscript 9.15 (2014-09-22)
Copyright (C) 2014 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GPL Ghostscript 9.15: **** Could not open the file \\spool\E312PS .
**** Unable to open the initial device, quitting.
GPL Ghostscript 9.15: **** Could not open the file \\spool\E312PS .
Unrecoverable error: ioerror in setpagedevice
Operand stack:
    true  --nostringval--  --nostringval--  --nostringval--  --nostringval--  --nostringval--  --nostringval--  --nostringval--  --nostringval--
gsapi_exit returns 0
DosFreeModule returns 12

I have no real idea what this means. E312PS is the name of my Postscript printer in eCS 2.1. If I use GhostScript 8.63 instead of 9.15, it prints the following in the printing status box, and printing succeeds:

GPL Ghostscript 8.63 (2008-08-01)
Copyright (C) 2008 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GPL Ghostscript 8.63: **** Could not open the file \\spool\E312PS .
page 1

So I guess my questions are these:
1) Why does Ghostscript 9.15 refuse printing because it can't open the file \\spool\E312PS, while 8.63 works?
2) What is the \\spool\E312PS file, and can I add it to my system so that 9.15 can work? I assume it is part of the printer queue somehow but don't understand exactly how.
3) Any other useful comments...

Best regards, Thomas Hellsén

10

Storage / Re: JFS partition corrupted -- what is the root cause, and how to fix it?

« on: September 14, 2014, 10:15:19 pm »

Thank you all who have answered so far.

Boris, Eirik: I tried running CHKDSK F: /F:3 from a command window in the management console in the eCS 2.1 installation program, and it states the following, accompanied by a number of short beeps:

The current hard disk drive is: F:
The type of file system for the disk is JFS.
The JFS file system program has been started.
Internal error: devices.c(532): Read error 23 (CRC)
Internal error: devices.c(532): Read error 23 (CRC)
JFS0068: CHKDSK  Superblock is corrupt and cannot be repaired because both
primary and secondary copies are corrupt.  CHKDSK CANNOT CONTINUE.

This does suggest that Doug is correct: the disk may indeed be going bad. It could definitely be worth copying the still-good E: partition and the backup of the F: partition to a new hard disk and see how that works. Then I can let DFSee do a long-time test of the drive and see if it comes out faulty.

Doug: I think I formatted the JFS partitions with eCS 1.2 before the eCS 1.2r update. I have no idea if the actual filesystem data differs between the two eCS versions' JFS implementations, but I haven't heard of any interoperability problems either. Not to say I hear or know much about that, though.
As for clean-marking the partition in DFSee, I assume the partition cannot be read at all (by eCS) since both superblocks are corrupted.

I have a backup that I made before transferring the hard disks to a new system, so most of the files on F: should be okay. It might be worth downloading JRescuer and see if it can do anything with the partition. If it can recover files, it may be worth buying it to recover those files I changed or added since the backup. It will take awhile to get this fixed but I'll post back when I have something new.
/Thomas

11

Storage / JFS partition corrupted -- what is the root cause, and how to fix it?

« on: September 14, 2014, 11:21:28 am »

Hi everybody,
I have a strange and quite annoying problem. I recently upgraded my computer, and now I'm having a problem with JFS partitions on one of the disks getting corrupted. I slightly suspect it happened after using a FAT32-formatted USB stick but I have no proof.
Has anyone had something similar happen, and is there anything I can do to recover the JFS partition?
Details follow.

Hard drives:
Disk 1: 10.2 GB, partitioned into C: (1.3 GB HPFS, eCS 1.2r) and D: (8.9 GB JFS, program/file storage)
Disk 2: 61.5 GB, partitioned into E: (1.26 GB HPFS, eCS 2.1) and F: (60.2 GB JFS, data/file storage)

After making a backup of all partitions except E:, I moved the hard drives to the new computer (see further below for details). I installed eCS 2.1 to the E: partition on a bootable JFS, since that has worked well on the laptop that I now use to write this. I also installed Air-Boot instead of the old IBM bootmanager.
The installation went well, and I started to install some applications. I also tested that I could use a FAT32-formatted 4 GB USB stick that I previously had let LVM designate as U: and had formatted in MS Windows.
But following a restart, the eCS 2.1 partition suddenly failed to boot. CHKDSK from eCS 1.2r couldn't handle the corruption. I thought then that maybe the bootable JFS was incompatible with eCS 1.2r and that it had corrupted the E: partition, or that I had an unlucky sector failure.
Since I hadn't really installed much of anything, I just re-installed eCS 2.1 on E:, this time selecting HPFS instead of bootable JFS. I went on installing new applications and configuring the system, also (last night) copying some data files to and from the 4 GB FAT32-formatted USB stick mentioned above.
Then I restarted the computer to see the effect of some new WPS classes. eCS 2.1 now hung in the JFS check during boot-up. The D: drive checked out, but the check on the F: drive just had stopped. After awhile of no disk activity, I restarted the system with Ctrl-Alt-Del.
Now Air-Boot complained that the there were boot sector problems and would not start. I restarted the system with a DFSee 11.5 CD (the latest I had burned; DFSee 12.1 was on D: but to no use). I used DFSee to make checks on the partitions, then recreated the boot sector on disk 2 and restarted.
Now Air-Boot comes up and I can boot either eCS 1.2r on C: or eCS 2.1 on E. but they both hang when they are about to start checking the JFS F: partition. None will finish booting. They just beep intermittently a few times, then do nothing.
I have used the management console in the eCS 2.1 installation to verify that partitions C: D: and E: are OK, but it can do nothing about the F: partition.

There is my problem (sorry for the long-winded description). So my two questions are:
1) Can I recover the JFS F: partition, or at least its data (I do have a backup but it would be good to know how I could restore the partition if I hadn't). Can I use DFSee, or should i buy JRescuer, or is there another solution?
2) What was the root cause of the problem? I do suspect the USB stick with FAT32, but I have nothing except the circumstantial evidence that it was used in the system before both corruptions.

Any useful information on the subject(s) would be appreciated.

Best regards,
Thomas Hellsén

PS Details on old & new computer setups below.

Previous hardware: PPI-556, a 266 MHz, 384 MiB tower model computer.
IDE controller 0: the hard drives as above.
IDE controller 1 had two CD/DVD drives:
CD 1:  Plextor Plexwriter (CD only)
CD 2:  CD/DVD reader.
This setup had worked reliably for many years, not a glitch really, but it was getting old and the power supply fan had failed.

E: was a maintenance partition that I planned to upgrade to eCS 2.1 and be the main OS after the switch.
I first made a backup of the partitions to a USB-connected HD, then moved the drives to the new hardware:

IBM ThinkCentre A30, 2.8 GHz, 1 GiB tower model computer, bought used.
Connected the hard drives to IDE controller 0, like above.
IDE controller 1:
CD 2:  CD/DVD reader.
CD 1:  Plextor Plexwriter (CD only) from previous hardware.