OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: Pete on April 16, 2017, 03:22:03 am

Title: configuring the rpm release of cups
Post by: Pete on April 16, 2017, 03:22:03 am
Hi All

Thought I'd give the rpm version of cups a try so installed the ANPM, fired it up and took a guess that the package simply called cups would get everything downloaded and installed.

Well, that was successful - ANPM tells me everything got downloaded and installed. I then rebooted for libpath changes to take effect.

Now, how do I go about configuring cups?

I started the cupsd.exe as a detached process and fired up Seamonkey - except Seamonkey would not start. As Seamonkey was running fine prior to installing the cups files I can only guess that a file installed as part of the cups installation does not work with Seamonkey version 2.35a2. I updated Seamonkey to version 2.35b7 which made no difference. Interestingly pmdll reckoned both versions of Seamonkey worked fine...

Having compared this system with my main system where Seamonkey 2.35b7 works fine I installed the current pango100.dll  and now have a working Seamonkey on that system.

I pointed Seamonkey to http://localhost:631/ which results in a "Failed to connect. The connection was refused ... Though the site seems valid the browser was unable to establish a connection"

Does the rpm version of cups not have a working browser interface?

As it seems ages since I last configured a cups printer using the command line I thought I'd refresh my memory by having a read of the docs starting with /usr/share/doc/cups/index.html however it seems that the section I need called Adding printers and classes is not among the files installed as Seamonkey gives a ".../usr/share/doc/cups/admin cannot be found".

Someone said that using yum/rpm to install software would be easier? Maybe I am simply missing something, somewhere...


Regards

Pete


Title: Re: configuring the rpm release of cups
Post by: Andreas Schnellbacher on April 16, 2017, 02:14:04 pm
Interestingly pmdll reckoned both versions of Seamonkey worked fine...
PMDLL can't know which DLLs are loaded after program start. It depends on the type of DLL loading whether PMDLL checks all required DLLs. Of more value for the Mozilla apps is to check xul.dll instead. That has helped me several times.

Additionally, I would check the system for doubled DLL files. The directory \ecs\dll has many of them. I rename or delete all gcc*.dll, libc*.dll, stdcpp.dll and supcpp.dll from a freshly installed eCS 2.2 beta 2. IIRC, ANPM required also to replace vrobjex.dll of eCS.
Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 16, 2017, 07:30:00 pm
Hi Pete.

Is this a new RPM/YUM install, or have you kept it up to date as you installed various programs? Just installing ANPM (RPM/YUM) does not install all of the requirements for programs that you already have installed (like Seamonkey). You still need to install everything that is called for those programs. The ANPM bootstrap is only enough to make RPM/YUM smart enough to be able to do that.
Title: Re: configuring the rpm release of cups
Post by: Pete on April 16, 2017, 08:18:41 pm
Hi Doug

A new, never installed before, ANPM/yum/rpm.

I already had everything installed for Seamonkey to work fine. The actual process of installing ANPM/yum/rpm/cups packages seems to have installed a later version of a/some dll file/files which, it seems, was/were not backwards compatible.

I suspect yum/rpm are best installed during OS installation to avoid the problems that can be encountered by adding them at a later date.

However, the real question is: Does the rpm cups release actually work? Followed by how to setup a printer? and Can I use the bjnp port from my non-rpm cups install? - if not then the exercise is in vain anyway. Presumably I will have to select to install gutenprint as that did not get automatically selected during installation?


Regards

Pete


Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 17, 2017, 04:50:56 am
Quote
I already had everything installed for Seamonkey to work fine. The actual process of installing ANPM/yum/rpm/cups packages seems to have installed a later version of a/some dll file/files which, it seems, was/were not backwards compatible.

Precisely. In fact, you really should remove ALL of the old, manually installed stuff, but the YUM paths coming first should overcome that, although they still haven't figured out that the dot (./) entry will also cause problems, depending on what a user may have done in the past. There is also a lot more to it than just DLLs.

Quote
I suspect yum/rpm are best installed during OS installation to avoid the problems that can be encountered by adding them at a later date.

True. In fact, it is probably the only way to get it close to right. With an old, converted, install, you need to go through every program, and install all of the required packages (using ANPM), as called in the the program documentation, to be sure that they are the latest, and that they are in the right place. The biggest exposure is if you ever put something into a program directory, that should never be there, but some program specific support should be there, so it can be difficult to determine what to do with that stuff. One suggestion, is to uninstall the old software, make sure that nothing (except data) is left, then install it again. That should get rid of stray stuff that shouldn't be there.

Quote
However, the real question is: Does the rpm cups release actually work? Followed by how to setup a printer? and Can I use the bjnp port from my non-rpm cups install? - if not then the exercise is in vain anyway. Presumably I will have to select to install gutenprint as that did not get automatically selected during installation?

It works well, with my HP D110a, in ArcaOS, but the installer puts all of the parts in place. The printer configuration is done with the "Install Cups Printer" tool (CupsGUI). Gutenprint is installed, in the unixroot directory structure (it may have been put there by the ArcaOS installer). One thing that was found in early ArcaOS testing, was that it needs the "which" package, but didn't call it as being required. I don't know if that got fixed outside of the ArcaOS stuff, or even if it needs it (probably does).

I don't know about the bjnp support, but I am interested to know, because my brother has a Canon printer (MP620). It works pretty well, after fighting with it to get it going. Last time I set it up, I had to use an older version of bjnp to make it work, but that was about a year ago, and I am not sure which version of CUPS it was (probably 2.0).
Title: Re: configuring the rpm release of cups
Post by: Pete on April 17, 2017, 04:21:07 pm
Hi Doug

Well, installing cups here has not installed gutenprint. I guess it is not automatically selected as not all printers need the gutenprint support. Presumably mention of any necessary extra packages required happens sometime during the setting up of a cups printer?

You mention the "Install Cups Printer" tool (CupsGUI) but neglect to say where to find it - or is this something that should appear after the cups files were installed but did not? If you mean the browser based interface that does not work - possibly cupsd.exe is not starting, does not appear in any process list. Presumably cupsd (cups daemon) is started in a Startup folder but is the incantation different to the non-rpm cupsd.exe apart from path?

If you mean the Install/Manage Printer objects in the Desktop -> Local System ->Printers folder how do I switch those from German(?) to English to have a chance of setting up a printer? Resolved - simply copied the English version of printmen.msg from my main system.

No, I doubt you mean this printer install app as selecting Install a local or network printer (CUPS-based)  closes the app with nothing else happening.

When/If I eventually get to set up a cups(rpm) printer I will need to use the bjnp printer port; bjnp.exe 1.9.2 requires the installation of cups17.dll - something else that a user would have to know as cups(rpm) does not include the port or support file. I guess cups17.dll should be copied into /usr/lib where other cups related dll files live.

So far this yum/rpm installation of cups is harder work than installing from the (non-rpm) ecups zip files.


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: ivan on April 17, 2017, 06:37:15 pm
Pete, I think you have discovered the BIG problem with the rpm/yum method of installing anything - it is dumb and will not work if anything else is there and it has not been given exact specifications on what to install (just look at the 'migrating from native ghostscript' thread).

For the rpm/yum install method to work it need some way of setting up what it is supposed to install especially where there are several options that may, or may not, be required.
Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 17, 2017, 07:39:49 pm
Quote
Well, installing cups here has not installed gutenprint. I guess it is not automatically selected as not all printers need the gutenprint support. Presumably mention of any necessary extra packages required happens sometime during the setting up of a cups printer?

I don't think that setting up the printer will do it. I don't know what triggers installing it, other than selecting it.

Quote
You mention the "Install Cups Printer" tool (CupsGUI) but neglect to say where to find it

It is where it has always been: http://trac.netlabs.org/ecups/wiki/CupsPort (http://trac.netlabs.org/ecups/wiki/CupsPort).

Quote
possibly cupsd.exe is not starting, does not appear in any process list.

Well, that is the first problem to fix. Try starting it from a command line, it should either run (with a black screen), or fail with some sort of message.

Quote
No, I doubt you mean this printer install app as selecting Install a local or network printer (CUPS-based)  closes the app with nothing else happening.

CUPSD.EXE must be running.

Quote
When/If I eventually get to set up a cups(rpm) printer I will need to use the bjnp printer port; bjnp.exe 1.9.2 requires the installation of cups17.dll - something else that a user would have to know as cups(rpm) does not include the port or support file. I guess cups17.dll should be copied into /usr/lib where other cups related dll files live.

No, something like that, which is not managed by ANPM, should be in /usr/local/lib (which may not exist, but should be in LIBPATH). BJNP.EXE should be in /usr/local/sbin which should also be in the PATH statement, but may not exist.

Quote
So far this yum/rpm installation of cups is harder work than installing from the (non-rpm) ecups zip files.

So far, you haven't cleaned out the cruft from before, and that is probably causing grief. Did you use WarpIn to UNINSTALL all of the stuff that is replaced by YUM? Did you remove all of the things that you installed by ZIP? Did you UNINSTALL the old CUPS? Unfortunately, ANPM (YUM/RPM) does NOT do any of that for you, and that leaves a lot of possibilities for finding incorrect DLLs, and other things. As you noted, the best way to start with ANPM (RPM/YUM) is to start with a fresh install. There is a LOT of cleanup to do if you start with an old install.

Quote
For the rpm/yum install method to work it need some way of setting up what it is supposed to install especially where there are several options that may, or may not, be required.

The way that that is done, is to READ the program instructions, and install everything that it calls for, whether you think it is already installed, or not. The program sorts it out, and installs what you need (as long as the instructions are correct, and that has been known to be a problem sometimes).

You must remember that RPM/YUM is designed to have full control over your system. In *NIX that is the case. In OS/2, there are many other ways to do things, and RPM/YUM doesn't know about that.  The easy way to overcome that problem, is to simply remove all of the things that RPM/YUM doesn't control, and install them using RPM/YUM. The bad part about that, is that RPM/YUM doesn't have everything that you might need, so those things need to be installed in some other way. Once you get over the desire to control what is on your system, and just let RPM/YUM do it for you (using ANPM as a front end processor, to make it easy), it all starts to work properly.

Having said all of that, I will suggest that you go back to what was working, and start using RPM/YUM when you do a new install. It will make life a lot easier. Be assured, that CUPS works well, when properly installed, but CUPS is a pretty complicated program (as you well know), and getting all of the parts to work together takes some planning. CUPS, from RPM/YUM, is not the same as what you may have installed in other ways, it does require that everything works in the RPM/YUM way, and it won't cooperate if something is missing (or possibly duplicated elsewhere).

One problem, that I know about, is that there is a package called "sdl" (lower case), that will prevent an updated package "SDL" (upper case) from being installed. If "sdl" is installed, uninstall it, and install "SDL", but watch for other things that may be uninstalled with it. You may need to reinstall them. ffmpeg will install "sdl", if "SDL" is not already installed, for instance. That is a packaging problem, that nobody seems to want to fix.
Title: Re: configuring the rpm release of cups
Post by: ivan on April 17, 2017, 08:44:47 pm
Quote
The way that that is done, is to READ the program instructions, and install everything that it calls for, whether you think it is already installed, or not. The program sorts it out, and installs what you need (as long as the instructions are correct, and that has been known to be a problem sometimes).

In my mind it should be the responsibility of the installer to do the 'reading' of the instructions and then check what is installed, buildlevel etc., and check what options the person doing the install wants and only then install what is required.

In Pete's case it appears that it is not offering any options to install when it should be asking for, at least, the printer type if not the exact model.  This is not good especially when non technical people are trying to rely on it to install what they need to get their external equipment up and running.
Title: Re: configuring the rpm release of cups
Post by: Pete on April 18, 2017, 02:40:02 am
Hi Doug

Should there be some instructions with the cups package?

It seems that cupsd.exe does not want to start; using the command cupsd.exe in a command line window opened in /usr/sbin results in the prompt returning with no sign of an error - but cupsd.exe is not in the eComCenter dropdown Process list and TOP does not indicate it is running. Using "detach cupsd.exe" gives a PID but cupsd.exe is still not in the Process list or displayed by TOP. I had already set the LogLevel to debug and as no log gets generated I can only guess that cupsd.exe is not starting due to a missing support file...

The prior non-rpm cups install and support files should not be causing problems as the rpm stuff is before everything in Path and only preceded by the "." in LibPath. There are no config.sys entries for the non-rpm cups at all.


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: Andi B. on April 18, 2017, 08:33:07 am
Quote
In my mind it should be the responsibility of the installer to do the 'reading' of the instructions and then check what is installed, buildlevel etc.,...
You're kidding, do you? You mean scan ALL available drives (including maybe currently not accessible lan shares, ...) for every single dll the installer wants to install and check bldlevel (which does not exist for many files) and deleting stuff found on any other partition. Only think about how many builds Paul has offered for download - a big thank to him by the way - and then think about how an installer should decide which dll from which package is the best. And the other dlls an installer should delete? You ask for big troubles.

Back to the basics of rpm/yum. Put into your libpath/path the %unixroot%/... directories as suggested and done by ANPM to the front. If you need the .; put it after the %unixroot% dirs or at the end. Not before (unfortunately ANPM does not do it for you but leave it in front :(. Now all your rpm/yum stuff will run out of the box.

When you've done the above and cupsd.exe does still not run look at the error log. And yes cups is a big piece of software. There are a lot of things which can go wrong. But for me the rpm version was the first which I got running stable. And I tried different versions over the years....
Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 18, 2017, 05:49:43 pm
Quote
Should there be some instructions with the cups package?

ArcaOS contains instructions in %UNIXROOT%\usr\share\doc\cups-libs-* (expand to match your system), in multiple languages. I don't know if that is something that ArcaOS adds, or if it comes with the RPM download. In fact, there is nothing new there, as far as getting CUPSD.EXE to run.

Quote
TOP does not indicate it is running.

It does on my system, so it probably isn't running.

Do you have PMDLL? If so, drop CUPSD.EXE on it, and look for red entries. Be sure that you are in the correct directory.

Quote
only preceded by the "." in LibPath.

That might cause the problem, if the dot is finding something that shouldn't be there. Try removing the dot, and reboot, to test. I argue that the dot entry should come AFTER the *NIX stuff, but those who should know, say it should be first. Note, that ANPM will complain about that, if you run it. Just tell it to ignore it, but there is a setting to always ignore it, if you decide to use it that way.
Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 18, 2017, 06:24:30 pm
Quote
The way that that is done, is to READ the program instructions, and install everything that it calls for, whether you think it is already installed, or not. The program sorts it out, and installs what you need (as long as the instructions are correct, and that has been known to be a problem sometimes).

In my mind it should be the responsibility of the installer to do the 'reading' of the instructions and then check what is installed, buildlevel etc., and check what options the person doing the install wants and only then install what is required.

In Pete's case it appears that it is not offering any options to install when it should be asking for, at least, the printer type if not the exact model.  This is not good especially when non technical people are trying to rely on it to install what they need to get their external equipment up and running.

Best change your mind. In most cases, there is no bldlevel information, and date/time mean absolutely nothing. Packages that are installed by ANPM (RPM/YUM), should install all of the requirements, but that depends on the RPM package being properly done, and that has been known to be a problem, sometimes (those who package those things are still learning). Programs that are installed outside of ANPM, could automatically install the requirements, by executing the YUM commands, BUT, I am sure that you, and others, would complain loudly if they did that, plus that would assume that you have RPM/YUM installed, and have kept it up to date (this thread shows that that is not always the case).

CUPS install has NOTHING, at all, to do with the printer type, and model. That is done, by the user, using the CUPS package (CUPSD.EXE must run). There are two options, one is to use the CUPS tools to configure the printer, THEN, you must make an OS/2 printer object for it, the other is to use the CUPSWIZ tool, that is at netlabs. That does the CUPS configuration, and it makes the OS/2 printer object.
Title: Re: configuring the rpm release of cups
Post by: ivan on April 18, 2017, 06:44:39 pm
Quote
CUPS install has NOTHING, at all, to do with the printer type, and model.

So you are saying the the rpm/yum install installs all the various backends regardless of if they are needed or not.  I would have thought that the installer would at least want to know which printer type to allow it to install the correct backend.

Sorry but I am first and foremost an engineer and have this tendency to apply that thinking to computers and their software.  After all computers are supposed to be logical machines, but what I am seeing with this rpm/yum thing does not appear that logical.

Title: Re: configuring the rpm release of cups
Post by: Pete on April 18, 2017, 07:16:55 pm
Hi Doug

I checked cupsd.exe using pmdll with directory set to /usr/sbin - and no errors... Either pmdll is not working right or cupsd.exe goes into "hiding" after starting and cannot be seen by any system tools or the browser pointed at http://localhost:631/

As suggested by yourself and Andi B I have tried moving the ".;" to after the *nix libpath entries and rebooted with no change, cupsd.exe still does not seem to be running; No log entries generated by my attempts to start cupsd.exe

My best guess is that cupsd.exe is not running and that a(some) support file(s) is(are) missing.

How is cupsd.exe started on a working rpm-cups system? - Just wondering if there is any special incantation required.

Regarding choice of printer make/model: As gutenprint was not installed during cups installation I doubt my printer - and many others - will be available for selection during the setting up a cups printer stage. There should be something at the cups installation stage asking the user what, if any, support package to install along with information to help the user make a, hopefully correct, choice.


Regards

Pete

Title: Re: configuring the rpm release of cups
Post by: ak120 on April 18, 2017, 07:27:31 pm
In most cases this so-called CUPS from RPM packages is only a makeshift. There are better workarounds for printing from OS/2 applications than this half-baked stuff. It's simply a waste of drive space on almost every client machine. And why should somebody in real world run CUPS under Warp Server? It's easier to keep it on UNIX servers where it really works and can be managed reliably. I'm only aware of a few Java applications that use IPP only for communication with IPP-capable servers like CUPS. It seems also to be a waste of time to explain UNIX printing system administration to unseasoned OS/2 users which simply want to print something with their local or network printers at home. A good example for an alleged solution that creates more problems than it solves.
Title: Re: configuring the rpm release of cups
Post by: ak120 on April 18, 2017, 07:37:43 pm
I checked cupsd.exe using pmdll with directory set to /usr/sbin - and no errors... Either pmdll is not working right or cupsd.exe goes into "hiding" after starting and cannot be seen by any system tools or the browser pointed at http://localhost:631/

Please first check your IP configuration. The particular interface has to be actived and up when cupsd shall run. The next step would be to examine your name resolvers. Should be quite easy by using netstat.

Everything else at this state would be pure guess.
Title: Re: configuring the rpm release of cups
Post by: Andi B. on April 18, 2017, 08:26:08 pm
Is localhost configured? You can post your \mptn\bin\setup.cmd to check.

cupsd runs from command line fine. Just type 'cupsd' from your %unixroot%\usr\sbin directory. If it immediately exits then which return value do you see? Cupsd exist immediately f.i. if another cupsd is running. Use 'prompt $r $p$g' before starting cupsd if you've not set up your prompt for displaying return values. No entry in popuplog.os2? Nothing in %unixroot%/var/log/cups?
Title: Re: configuring the rpm release of cups
Post by: Pete on April 18, 2017, 10:16:26 pm
Hi All

Yes, localhost is configured - the non-rpm cups had no trouble accessing the cups browser interface.

I tried entering cupsd on the command line. The prompt returns with no return value:-

[I:\USR\SBIN]prompt $r$p$g

0I:\USR\SBIN>cupsd

1I:\USR\SBIN>


There are no cups related entries in popuplog.os2 and no cups error log is generated.

@Andreas
Not sure what your solution is for getting printed output from recent/current inkjet printers but the only thing I have found that works is the (non-rpm) port of cups.


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 19, 2017, 12:59:00 am
Quote
My best guess is that cupsd.exe is not running and that a(some) support file(s) is(are) missing.

That would be my best guess too, but it is possible that the current version in netlabs-rel, is not the same as what ArcaOS is installing. According to ANPM, it is cups 2.1.3-7 i686 version, with:
cups-client 2.1.3-7
cups-filters 2.1.3-7
cups filters-libs 2.1.3-7
cups-libs 2.1.3-7
ghostscript-fonts 6.0-1
gnu-ghostscript 9.14-1
gutenprint 5.2.11-3
gutenprint-cups 5.2.11-3
gutenprint-libs 5.2.11-3

I also have the hplip stuff, which you may not need. There are probably other things involved, which is why you should use ANPM (RPM/YUM) to install it..

Quote
How is cupsd.exe started on a working rpm-cups system? - Just wondering if there is any special incantation required.

It is the same as before:
Code: [Select]
Path and file name:  CMD.EXE
Parameters:   /c detach cupsd.exe
in the STARTUP folder.

Try this: go to a command line, and type "PKILL CUPSD" (without the quotes). If it is running, it will kill it, and tell you so (you need to do that 4 times to completely kill it). When it is dead, PKILL will say that it failed to find CUPSD. If CUPSD is already running, detached, and you try to start it from the command line, it will just terminate, with no messages (which seems to be what you are seeing). If CUPSD is running, you should be able to open your browser, and go to web page:  localhost:631 and the CUPS home page should open (but you know that part).

So, first, lets Pkill CUPSD, to see if it is, or is not, running. Once it is dead, try starting it from a command line (no paths should be needed), without using detach. Then, you should be able to see what it is doing. It will simply start, and nothing more will happen, if it is running.

One other thought: Do you have a firewall that is blocking it?
Title: Re: configuring the rpm release of cups
Post by: Pete on April 19, 2017, 03:19:42 am
Hi Doug

I've removed my non-rpm cups/ghostscript/gutenprint installations from the system completely to avoid any possibility of the wrong files being used.

I uninstalled the rpm cups packages using ANPM and rebooted - probably not necessary...

I fired up ANPM: Selecting to install cups results in the same cups 2.1.3-7 packages being installed as you have listed, the cups filters packages are 1.8.2-5 plus cups-filesystem 2.1.3-7 with ghostscript 9.18-5 and ghostscript-fonts 6.0-1. No gutenprint packages installed - but that should not make a difference to whether cupsd.exe runs.

No, cupsd.exe does not run; PKILL "Failed to find PID for CUPSD.EXE" - pretty much what TOP had already indicated.

There is not a firewall blocking cupsd.exe - the non-rpm version ran fine.

My best guess is still that support file(s) is(are) missing as cupsd.exe does not start - not a good advert for the yum/rpm way of doing things I'm sorry to say.

Where do I report a problem with a rpm package?


Regards

Pete



Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 19, 2017, 04:42:59 am
Quote
Where do I report a problem with a rpm package?

https://trac.netlabs.org/rpm (https://trac.netlabs.org/rpm) should work. You may need a logon ID, if you haven't got one for Netlabs Trac. However, it may be better to go to the CUPS Trac.

Quote
No gutenprint packages installed - but that should not make a difference to whether cupsd.exe runs.

You wouldn't think so, but that stuff is so tightly integrated that I wouldn't bet on it.

Anyway, using an ArcaOS system, here is a PMDLL analysis of CUPSD.EXE:

Code: [Select]
DLL tree - M:\USR\SBIN\CUPSD.EXE                                         Page 1
--------------------------------------------------------------------------------

CUPSD.EXE┐
         ├LIBC066.DLL─┐
         │            ├DOSCALL1.DLL┐
         │            │            └SESMGR.DLL──┐
         │            │                         └DOSCALL1.DLL
         │            ├NLS.DLL─────┐
         │            │            └DOSCALL1.DLL
         │            ├KBDCALLS.DLL┐
         │            │            └DOSCALL1.DLL
         │            └VIOCALLS.DLL┐
         │                         └DOSCALL1.DLL
         ├CUPS.DLL────┐
         │            ├LIBC066.DLL
         │            ├URPO.DLL────┐
         │            │            ├LIBC066.DLL
         │            │            ├DOSCALL1.DLL
         │            │            └GCC1.DLL────┐
         │            │                         └LIBC066.DLL
         │            ├GCC1.DLL
         │            ├Z.DLL───────┐
         │            │            └Z1.DLL──────┐
         │            │                         ├LIBC066.DLL
         │            │                         └LIBCX0.DLL──┐
         │            │                                      ├LIBC066.DLL
         │            │                                      ├DOSCALL1.DLL
         │            │                                      └GCC1.DLL
         │            ├PTHR01.DLL──┐
         │            │            ├LIBC066.DLL
         │            │            ├DOSCALL1.DLL
         │            │            └GCC1.DLL
         │            ├TCPIP32.DLL─┐
         │            │            ├DOSCALL1.DLL
         │            │            └MSG.DLL─────┐
         │            │                         └DOSCALL1.DLL
         │            └DOSCALL1.DLL
         ├CUPSMIM.DLL─┐
         │            ├LIBC066.DLL
         │            ├CUPS.DLL
         │            └GCC1.DLL
         ├URPO.DLL
         ├GCC1.DLL
         ├TCPIP32.DLL
         └DOSCALL1.DLL
DLL tree - M:\USR\SBIN\CUPSD.EXE                                         Page 2
--------------------------------------------------------------------------------

Module        : LIBC066.DLL
Loaded from   : M:\usr\lib\LIBC066.DLL
File size     : 1,361,663 bytes
File date/time: 08-08-16 10:16:20 am

Module        : DOSCALL1.DLL
Loaded from   : M:\OS2\DLL\DOSCALL1.DLL
File size     : 132,401 bytes
File date/time: 11-24-11 03:24:00 am

Module        : SESMGR.DLL
Loaded from   : M:\OS2\DLL\SESMGR.DLL
File size     : 1,536 bytes
File date/time: 04-08-17 05:12:26 pm

Module        : DOSCALL1.DLL
Loaded from   : M:\OS2\DLL\DOSCALL1.DLL
File size     : 132,401 bytes
File date/time: 11-24-11 03:24:00 am

Module        : NLS.DLL
Loaded from   : M:\OS2\DLL\NLS.DLL
File size     : 512 bytes
File date/time: 04-08-17 05:12:28 pm

Module        : DOSCALL1.DLL
Loaded from   : M:\OS2\DLL\DOSCALL1.DLL
File size     : 132,401 bytes
File date/time: 11-24-11 03:24:00 am

Module        : KBDCALLS.DLL
Loaded from   : M:\OS2\DLL\KBDCALLS.DLL
File size     : 1,024 bytes
File date/time: 04-08-17 05:12:26 pm

Module        : DOSCALL1.DLL
Loaded from   : M:\OS2\DLL\DOSCALL1.DLL
File size     : 132,401 bytes
File date/time: 11-24-11 03:24:00 am

Module        : VIOCALLS.DLL
Loaded from   : M:\OS2\DLL\VIOCALLS.DLL
File size     : 2,048 bytes
File date/time: 04-08-17 05:12:26 pm

Module        : DOSCALL1.DLL
Loaded from   : M:\OS2\DLL\DOSCALL1.DLL
File size     : 132,401 bytes
File date/time: 11-24-11 03:24:00 am

Module        : CUPS.DLL
Loaded from   : M:\usr\lib\CUPS.DLL
File size     : 280,632 bytes
File date/time: 05-12-16 02:18:50 pm

DLL tree - M:\USR\SBIN\CUPSD.EXE                                         Page 3
--------------------------------------------------------------------------------

Module        : LIBC066.DLL
Loaded from   : M:\usr\lib\LIBC066.DLL
File size     : 1,361,663 bytes
File date/time: 08-08-16 10:16:20 am

Module        : URPO.DLL
Loaded from   : M:\usr\lib\URPO.DLL
File size     : 2,944 bytes
File date/time: 06-30-16 10:51:26 am

Module        : LIBC066.DLL
Loaded from   : M:\usr\lib\LIBC066.DLL
File size     : 1,361,663 bytes
File date/time: 08-08-16 10:16:20 am

Module        : DOSCALL1.DLL
Loaded from   : M:\OS2\DLL\DOSCALL1.DLL
File size     : 132,401 bytes
File date/time: 11-24-11 03:24:00 am

Module        : GCC1.DLL
Loaded from   : M:\usr\lib\GCC1.DLL
File size     : 28,871 bytes
File date/time: 02-01-15 03:32:06 pm

Module        : LIBC066.DLL
Loaded from   : M:\usr\lib\LIBC066.DLL
File size     : 1,361,663 bytes
File date/time: 08-08-16 10:16:20 am

Module        : GCC1.DLL
Loaded from   : M:\usr\lib\GCC1.DLL
File size     : 28,871 bytes
File date/time: 02-01-15 03:32:06 pm

Module        : Z.DLL
Loaded from   : M:\usr\lib\Z.DLL
File size     : 3,140 bytes
File date/time: 01-25-17 04:47:20 am

Module        : Z1.DLL
Loaded from   : M:\usr\lib\Z1.DLL
File size     : 58,794 bytes
File date/time: 01-25-17 04:47:20 am

Module        : LIBC066.DLL
Loaded from   : M:\usr\lib\LIBC066.DLL
File size     : 1,361,663 bytes
File date/time: 08-08-16 10:16:20 am

Module        : LIBCX0.DLL
Loaded from   : M:\usr\lib\LIBCX0.DLL
File size     : 22,128 bytes
File date/time: 01-18-17 03:51:16 pm

DLL tree - M:\USR\SBIN\CUPSD.EXE                                         Page 4
--------------------------------------------------------------------------------

Module        : LIBC066.DLL
Loaded from   : M:\usr\lib\LIBC066.DLL
File size     : 1,361,663 bytes
File date/time: 08-08-16 10:16:20 am

Module        : DOSCALL1.DLL
Loaded from   : M:\OS2\DLL\DOSCALL1.DLL
File size     : 132,401 bytes
File date/time: 11-24-11 03:24:00 am

Module        : GCC1.DLL
Loaded from   : M:\usr\lib\GCC1.DLL
File size     : 28,871 bytes
File date/time: 02-01-15 03:32:06 pm

Module        : PTHR01.DLL
Loaded from   : M:\usr\lib\PTHR01.DLL
File size     : 6,894 bytes
File date/time: 12-29-15 09:06:24 am

Module        : LIBC066.DLL
Loaded from   : M:\usr\lib\LIBC066.DLL
File size     : 1,361,663 bytes
File date/time: 08-08-16 10:16:20 am

Module        : DOSCALL1.DLL
Loaded from   : M:\OS2\DLL\DOSCALL1.DLL
File size     : 132,401 bytes
File date/time: 11-24-11 03:24:00 am

Module        : GCC1.DLL
Loaded from   : M:\usr\lib\GCC1.DLL
File size     : 28,871 bytes
File date/time: 02-01-15 03:32:06 pm

Module        : TCPIP32.DLL
Loaded from   : M:\MPTN\DLL\TCPIP32.DLL
File size     : 87,504 bytes
File date/time: 08-16-11 06:01:00 am

Module        : DOSCALL1.DLL
Loaded from   : M:\OS2\DLL\DOSCALL1.DLL
File size     : 132,401 bytes
File date/time: 11-24-11 03:24:00 am

Module        : MSG.DLL
Loaded from   : M:\OS2\DLL\MSG.DLL
File size     : 512 bytes
File date/time: 04-08-17 05:12:26 pm

Module        : DOSCALL1.DLL
Loaded from   : M:\OS2\DLL\DOSCALL1.DLL
File size     : 132,401 bytes
File date/time: 11-24-11 03:24:00 am

DLL tree - M:\USR\SBIN\CUPSD.EXE                                         Page 5
--------------------------------------------------------------------------------

Module        : DOSCALL1.DLL
Loaded from   : M:\OS2\DLL\DOSCALL1.DLL
File size     : 132,401 bytes
File date/time: 11-24-11 03:24:00 am

Module        : CUPSMIM.DLL
Loaded from   : M:\usr\lib\CUPSMIM.DLL
File size     : 11,163 bytes
File date/time: 05-12-16 02:18:50 pm

Module        : LIBC066.DLL
Loaded from   : M:\usr\lib\LIBC066.DLL
File size     : 1,361,663 bytes
File date/time: 08-08-16 10:16:20 am

Module        : CUPS.DLL
Loaded from   : M:\usr\lib\CUPS.DLL
File size     : 280,632 bytes
File date/time: 05-12-16 02:18:50 pm

Module        : GCC1.DLL
Loaded from   : M:\usr\lib\GCC1.DLL
File size     : 28,871 bytes
File date/time: 02-01-15 03:32:06 pm

Module        : URPO.DLL
Loaded from   : M:\usr\lib\URPO.DLL
File size     : 2,944 bytes
File date/time: 06-30-16 10:51:26 am

Module        : GCC1.DLL
Loaded from   : M:\usr\lib\GCC1.DLL
File size     : 28,871 bytes
File date/time: 02-01-15 03:32:06 pm

Module        : TCPIP32.DLL
Loaded from   : M:\MPTN\DLL\TCPIP32.DLL
File size     : 87,504 bytes
File date/time: 08-16-11 06:01:00 am

Module        : DOSCALL1.DLL
Loaded from   : M:\OS2\DLL\DOSCALL1.DLL
File size     : 132,401 bytes
File date/time: 11-24-11 03:24:00 am

M: is the drive where %UNIXROOT% lives. It is also the boot drive (but they don't need to be the same drive). This list is also much larger than what I see in an older version, as installed by WarpIn. Also note, that there is a DOSCALL1 package in RPM/YUM. That one is probably down level, and you should use the one that comes with the USB drivers that you are using.
Title: Re: configuring the rpm release of cups
Post by: ak120 on April 19, 2017, 10:29:05 am
Hi All

Yes, localhost is configured - the non-rpm cups had no trouble accessing the cups browser interface.

I tried entering cupsd on the command line. The prompt returns with no return value:-

Please run from command line: cupsd -t

Quote
There are no cups related entries in popuplog.os2 and no cups error log is generated.

It's certainly possible that the RPM package contains erroneous configuration files. Simply remove or rename them. It seems the packager or half-porter has no clue about CUPS administration.

Quote
Not sure what your solution is for getting printed output from recent/current inkjet printers but the only thing I have found that works is the (non-rpm) port of cups.

Simply using PCL or PostScript to network connected printers. It works also for chinese devices from the garbage disposal.
Title: Re: configuring the rpm release of cups
Post by: Paul Smedley on April 19, 2017, 11:44:37 am
Hey Pete,

I've removed my non-rpm cups/ghostscript/gutenprint installations from the system completely to avoid any possibility of the wrong files being used.

I uninstalled the rpm cups packages using ANPM and rebooted - probably not necessary...

I fired up ANPM: Selecting to install cups results in the same cups 2.1.3-7 packages being installed as you have listed, the cups filters packages are 1.8.2-5 plus cups-filesystem 2.1.3-7 with ghostscript 9.18-5 and ghostscript-fonts 6.0-1. No gutenprint packages installed - but that should not make a difference to whether cupsd.exe runs.

No, cupsd.exe does not run; PKILL "Failed to find PID for CUPSD.EXE" - pretty much what TOP had already indicated.

There is not a firewall blocking cupsd.exe - the non-rpm version ran fine.

My best guess is still that support file(s) is(are) missing as cupsd.exe does not start - not a good advert for the yum/rpm way of doing things I'm sorry to say.

Where do I report a problem with a rpm package?

Firstly, I have ZERO experience with rpm, and in particular the rpm version of cups, however, the concepts should be the same as the non-rpm cups.

1) Enable debug logging - on a non-rpm system, this is done my tweaking /cups/etc/cups/cupsd.conf - this is likely in /etc ? - change the line that is something like 'Loglevel info' to 'Loglevel debug' - then restart cupsd
2) check error_log - liek in /var/log/cups/error_log - post the output here.... it will likely show something enlightening...

Cheers,

Paul
Title: Re: configuring the rpm release of cups
Post by: Pete on April 19, 2017, 04:20:36 pm
Hi All

@Paul
I think I can honestly say that I have some experience of tracking down problems with non-rpm builds of cups  :-)
Yes, LogLevel has been set to debug.
No, there is no log generated. It seems that cupsd.exe is not starting at all hence my suspicion that a(some) required support file(s) is(are) missing.

@Andreas
I entered cupsd -t at a command prompt in /user/sbin.
The result is:-
"/@unixroot/etc/cups/cups-files.conf" contains errors.

I had a look at cups-files.conf but have idea what the error(s) are. Having copied cups-files.conf to a new name and deleted cups-files.conf I entered cupsd -t at the command line resulting in:-
"/@unixroot/etc/cups/cups-files.conf" is OK.
"/@unixroot/etc/cups/cupsd.conf" is OK.

I do wonder what cupsd is checking as cups-files.conf no longer exists - and, No, cupsd.exe is not running. I thought cupsd may be using cups-files.conf.default so copied that to cups-files.conf. That results in the "/@unixroot/etc/cups/cups-files.conf" contains errors. message when trying to start cupsd so I guess that is not the answer.

Also of interest: When cups-files.conf exists no logs are created. With cups-files.conf deleted access, error and page logs get created. Sadly they are not very helpful being 0 bytes in length...

I guess it indicates that cupsd.exe did try to start.


@Doug
Yes, the pmdll tree matches. There are some differences in file versions in use but seem to be "re-dating" exercises ie I have the following which have earlier dates than yours which look like they are dated 2017 (AN OS5?)
DOSCALL1.DLL 132,401 bytes 17-01-13
SESMGR.DLL 1,536 bytes 08-03-02
NLS.DLL 512 bytes 08-03-02


Maybe the answer is to try a known to be working cups-files.conf - although I am surprised that the supplied file contains errors. I also suspect this could be a symptom rather than the cause of cupsd.exe not running.


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: ak120 on April 19, 2017, 07:55:35 pm
@Andreas
I entered cupsd -t at a command prompt in /user/sbin.
The result is:-
"/@unixroot/etc/cups/cups-files.conf" contains errors.

I had a look at cups-files.conf but have idea what the error(s) are. Having copied cups-files.conf to a new name and deleted cups-files.conf I entered cupsd -t at the command line resulting in:-
"/@unixroot/etc/cups/cups-files.conf" is OK.
"/@unixroot/etc/cups/cupsd.conf" is OK.
At least it means you can run cupsd and don't have to go through DLL hell further. ;-)

Quote
I do wonder what cupsd is checking as cups-files.conf no longer exists - and, No, cupsd.exe is not running. I thought cupsd may be using cups-files.conf.default so copied that to cups-files.conf. That results in the "/@unixroot/etc/cups/cups-files.conf" contains errors. message when trying to start cupsd so I guess that is not the answer.

Comment the following line from cupsd.conf:
Listen /@unixroot/var/run/cups/cups.sock
I don't believe that those kinds of "ports" really use unix domain sockets. At least I could not find any indication in the sources that there are calls to local socket functions from AnyNet/2 or DCE. I don't know about the used C library, but that would be a surprise. So I hope somebody can prove me wrong.

And then simply run cups -f without erroneous cups-files.conf of course.

Quote
Also of interest: When cups-files.conf exists no logs are created. With cups-files.conf deleted access, error and page logs get created. Sadly they are not very helpful being 0 bytes in length...

I guess it indicates that cupsd.exe did try to start.

There should be something in file error_log now.

The best advise I can give: Stay away from as much crappy rpm packages as possible! Better use the latest CUPS compiled by Paul. It's not perfect or complete but it works to some degree if you really want to play with cups.
Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 19, 2017, 11:06:11 pm
Quote
@Doug
Yes, the pmdll tree matches. There are some differences in file versions in use but seem to be "re-dating" exercises ie I have the following which have earlier dates than yours which look like they are dated 2017 (AN OS5?)
DOSCALL1.DLL 132,401 bytes 17-01-13
SESMGR.DLL 1,536 bytes 08-03-02
NLS.DLL 512 bytes 08-03-02

They are likely updated for ArcaOS, but I don't think any of them would cause, or fix, your problem. I could be wrong.

Quote
Maybe the answer is to try a known to be working cups-files.conf - although I am surprised that the supplied file contains errors. I also suspect this could be a symptom rather than the cause of cupsd.exe not running.

There should be a default file, and it should work. If not, I don't know what else you can do. As I noted before, there may be something new in ArcaOS, that isn't in the RPM packages, yet, but I would think that CUPSD.EXE should run.
Title: Re: configuring the rpm release of cups
Post by: Pete on April 19, 2017, 11:11:22 pm
Hi Andreas

I had already commented out the Listen /@unixroot/var/run/cups/cups.sock line in cupsd.conf - mainly because there is no file /var/run/cups/cups.sock which may have been totally the wrong reason but works fine with Pauls cups builds.

Using cupsd -f with no cups-file.conf present seems to work though - which seems to indicate that cups-files.conf does really contain errors - and I can now access printer configuration using a browser. I have no idea what beh.exe is or why it should be offered as a network connection though.

Of course that leads on to a different problem when trying to print the cups testpage - "Filter failed". Now to troll through the error_log and see what happened...

Oh that is helpful - a username and password is required to access the log files using the browser interface.

I killed cupsd and opened the log with a text editor. aha!  gstoraster stopped with status 11. Which means absolutely nothing to me except that the process failed...


Regards

Pete



Title: Re: configuring the rpm release of cups
Post by: Paul Smedley on April 19, 2017, 11:59:59 pm
Hi Pete,

I killed cupsd and opened the log with a text editor. aha!  gstoraster stopped with status 11. Which means absolutely nothing to me except that the process failed...

11 should be the value of errno.
From /usr/include/sys/errno.h
#define   EDEADLK      11      /* Resource deadlock avoided */

This probably isn't helpful though :) debug2 logging might have some more output that tells us why gstoraster failed.

Cheers,

Paul
Title: Re: configuring the rpm release of cups
Post by: Pete on April 20, 2017, 03:27:43 am
Hi Paul

LogLevel is already at debug2... which is very verbose, 598Kb, and even when chopped down to the section that covers just the print job is still 433Kb.

All 4 filters involved -  bannertopdf, pdftopdf, gstoraster and rastertogutenprint.5.2 - are reported as successfully started as is the bjnp backend.
2 filters - bannertopdf and pdftopdf - are reported as "exited with no errors".
The next thing that catches my eye is the gstoraster stopped with status 11 with no obvious reason in the log.

I used pmdll to check gstoraster should work ie no support files missing.

What would cause a "Resource deadlock"? Could gstoraster be trying to process a file that is not yet ready for processing? Or is this a hardware resource problem?


Regards

Pete






Title: Re: configuring the rpm release of cups
Post by: Pete on April 23, 2017, 01:35:05 am
Hi All

As a result of reporting the cups-files.conf problem we now have the answer as to why cupsd -t reports ""/@unixroot/etc/cups/cups-files.conf" contains errors.".

It seems that something called klusmgr (KLIBC User management) *must* be installed and run to setup users/groups.

I am informed that ArcaOS handles this as does the latest version of klibc - probably why Doug was not having this problem.

The gstoraster problem has also been reported so will post update when/if resolved.


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: ak120 on April 23, 2017, 12:49:29 pm
Hi All

As a result of reporting the cups-files.conf problem we now have the answer as to why cupsd -t reports ""/@unixroot/etc/cups/cups-files.conf" contains errors.".

It seems that something called klusmgr (KLIBC User management) *must* be installed and run to setup users/groups.
RPM should do it automatically. But almost every RPM package is broken in several ways or is missing the correct dependencies. And as with most pre-alpha software there's no documentation.

How well this KLIBC user management integrates with UPM?
Title: Re: configuring the rpm release of cups
Post by: guzzi on April 23, 2017, 05:03:06 pm
Hi Andreas,

Can you prove your claim that almost rpm package is broken? Everything I have installed here (>100) seems to work fine.
Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 23, 2017, 07:11:36 pm
Quote
It seems that something called klusmgr (KLIBC User management) *must* be installed and run to setup users/groups.

Apparently, that isn't true. The Samba server Users and Groups thing will do the job.

Quote
I am informed that ArcaOS handles this as does the latest version of klibc - probably why Doug was not having this problem.

No, that has nothing to do with ArcaOS, although it will appear when you do the ANPM (RPM/YUM) update that includes it. I never saw it, before a few days ago, and it was not part of ArcaOS, until it got installed by ANPM. Certainly not required for the CUPS that ArcaOS installs.

So far, there are no real docs for it, so I really don't know what it is all about. Ask Bitwiseworks, it is something that they did.

Quote
The gstoraster problem has also been reported so will post update when/if resolved.

Somehow, this would seem to be that you need the "which" package installed (mentioned earlier, I think). Without it, CUPS cannot find the programs that are needed. However, that won't stop CUPSD.EXE from running, unless there is something different in what ArcaOS did.

Quote
Can you prove your claim that almost rpm package is broken? Everything I have installed here (>100) seems to work fine.

I will agree with that statement, up to a point. There are a few packages that do have problems. I have never tried to figure out which ones, and they usually get fixed shortly after the problems get reported. I suspect that most problems are harmless. I will also state that RPM/YUM was a bad choice to manage these things, but that is what it is. If you don't like it, either do something about it, or, stop using it.

Quote
How well this KLIBC user management integrates with UPM?

Let us know, when you figure it out. It doesn't mention UPM (whatever that is), so it probably doesn't have anything to do with it. From what I see, it is basically the same program that handles the Samba server Users and Groups stuff.
Title: Re: configuring the rpm release of cups
Post by: Dave Yeo on April 23, 2017, 07:51:08 pm
There are enough RPM packages that seem to be missing a dependency that it can be a hassle. Perhaps I see more due to installing developer stuff. Things like having to guess which of the 50 perl packages is needed by autoconf, now git wants to be updated but one of those 50 odd perl packages won't allow it. Need to file some bugs I guess. It's easy to forget what I did.
klusmgr just sets up the users and groups stuff in @UNIXROOT/etc, which is needed for some ports, sometimes it seems randomly. I had one git repository where git wanted a user and I ended up installing the samba server to make it happy as the samba stuff also set up the user and group stuff.
Don't seem to have it installed in ArcaOS but I haven't done anything with cups, no printer here.
Title: Re: configuring the rpm release of cups
Post by: Andreas Schnellbacher on April 23, 2017, 08:20:29 pm
I will also state that RPM/YUM was a bad choice to manage these things

I learned to not mix up the requirements of all ported POSIX apps and components with the requirements of a POSIX installer. We have that unpopular @UNIXROOT tree on our disk, but as you can see it from Dave's posting, the apps need it.

About the quality of available RPM packages: Yes, there exist bugs. New packages usually introduce new bugs. Note that the POSIX subsystem is really complex and it takes some time to be able to build a first RPM package, understanding the meaning of its macros.

We all can help to improve these packages. (Actually, everything I have installed woks well. BTW: I don't have CUPS installed.) Creating new entries (after searching the tracker for existing ones) in the bug tracker is valuable for everyone. The people at bww are quite responsible on that and make fixed versions available almost immediately.
Title: Re: configuring the rpm release of cups
Post by: Andi B. on April 23, 2017, 09:28:59 pm
RPM should do it automatically. But almost every RPM package is broken in several ways or is missing the correct dependencies. And as with most pre-alpha software there's no documentation.

How well this KLIBC user management integrates with UPM?
Given your infinite wisdom I wonder why you did not do any correct package by yourself. Or any other valuable contribution to the community. Or did I overlook any ported or written by yourself piece of software from you? Please point me to your work to try it out. It's a shame that a genius like you produces only drivel :-(
Title: Re: configuring the rpm release of cups
Post by: Pete on April 23, 2017, 11:22:13 pm
Hi Doug

I'm not using Samba so would not know about that option.

As regards inclusion of klusmgr in ArcaOS and klibc I am only repeating what I was told.

Yes, i have "which" installed but the problem is not that gstoraster cannot be found but that it fails in a resource deadlock.


I do not want to get drawn into any arguments about yum/rpm but this attempt at installing cups and required packages via ANPM/yum/rpm could have gone a lot better and it would be preferable if I had a working printer as a result.


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 24, 2017, 12:03:30 am
Quote
As regards inclusion of klusmgr in ArcaOS and klibc I am only repeating what I was told.

I have one test system where it has not been installed. The RPM/YUM version of CUPS works well, but I do use Samba server, so I had the password file to work with. AFAICT, the user ID and password are only needed to log in to look at the log files, but there may be other things internally. It certainly won't stop CUPSD.EXE from loading.

Quote
I do not want to get drawn into any arguments about yum/rpm but this attempt at installing cups and required packages via ANPM/yum/rpm could have gone a lot better and it would be preferable if I had a working printer as a result.

Installing CUPS, and getting it to work, has always been a problem, but the ArcaOS installation works right out of the box, for me. There is obviously something in ArcaOS, that isn't in the CUPS packages. I have no idea what that might be. My HP D110a printer configures, and works well, with it. I use the printer with WiFi, because the USB port is physically broken. When I visit my brother (in June), I will see what happens with his Canon printer.

I haven't looked, but there may be some updated packages in the netlabs-exp repository. I would suggest that you look, but you need to be very careful with that stuff, because it hasn't been released to the netlabs-rel repository for a reason (not enough testing).
Title: Re: configuring the rpm release of cups
Post by: Pete on April 24, 2017, 02:31:10 am
Hi Doug

Well, cupsd.exe would not start due to errors in cups-files.conf, cupsd -t reports errors with cups-files.conf

After installing and running klusmgr - which creates the files group and master.passwd in %UNIXROOT%/etc - cupsd works fine, cupsd -t no longer reports errors with cups-files.conf

So, Yes, in this instance it was necessary in order to get cupsd.exe running. Obviously if you already have the above files generated by another app it is unnecessary.

It may be worth trying the later builds in the experimental repo - after all, I am experimenting to see what works  :-)


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: Andi B. on April 24, 2017, 08:08:20 am
....There is obviously something in ArcaOS, that isn't in the CUPS packages. I have no idea what that might be....
I don't think so. I've running rpm/cups since the beginning when no ArcaOS exists. But given Pete solves the problem with klusmgr it seems to be some user rights management problem. Probably you do not see it cause Samba is always installed with ArcaOS AFAIK. Samba users have the full 'user right management thing' (whatever this is) installed and do not need klusmgr. And so cups seems to be happy for ArcaOS users or people like me who have samba running anyway.

From Petes experience it seems you need either the Samba 'user rights thing' or that one from klusmgr (NOT BOTH). Didn't look into the documentation but maybe this is missed in the cups readme and worth to create a ticket for.
Title: Re: configuring the rpm release of cups
Post by: Pete on April 24, 2017, 03:23:15 pm
Hi Andi

What cups readme? - that is also missing.

It seems that a user needs to know where to look for documentation despite never having used yum/rpm to install software previously.

That is something that the yum/rpm people need to look into.


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 25, 2017, 07:47:33 am
Quote
What cups readme? - that is also missing.

It seems that a user needs to know where to look for documentation despite never having used yum/rpm to install software previously.

That is something that the yum/rpm people need to look into.

Have you opened an incident for it (assuming somebody else hasn't done so already)? That is really a packaging problem, that should be fixed. Building RPM packages is more of an art, than a science, and CUPS is probably the most complicated package in the whole works (not a good one to start learning with). The people responsible won't know that you have a problem, if you don't tell them. I am pretty sure that they don't have time to hang out here.

FWIW, the last time I looked, the documentation was at netlabs, where it has been for a long time. Whether it has been updated, is a whole different question.
Title: Re: configuring the rpm release of cups
Post by: Pete on April 25, 2017, 03:52:31 pm
Hi All

At the moment it seems that the gstoraster problem is caused by attempting to use the non-rpm supplied bjnp.exe plus cups17.dll to provide the correct backend.

Sadly this means that at this point in time the rpm releases of cups are of absolutely no use to anyone with a recent/current Canon inkjet printer that uses the bjnp port as there is no way of outputting to the printer.


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 25, 2017, 08:16:43 pm
Quote
At the moment it seems that the gstoraster problem is caused by attempting to use the non-rpm supplied bjnp.exe plus cups17.dll to provide the correct backend.

The problem may be with the handling of cups17.dll. Dlls, in RPM/YUM, have been modified to provide multiple forwarding capabilities (or something like that) to account for different versions. Open an incident, and see what they have to say. I will try it with my brother's Canon MP620 printer, sometime in June, but I will probably use ArcaOS to do it. You could also try an older BJNP, if you can find it.

It is also possible, that the sockets backend will now support the Canon WiFi printers (but I wouldn't bet on it).

Have you tried a USB connection?
Title: Re: configuring the rpm release of cups
Post by: Pete on April 25, 2017, 09:39:18 pm
hi Doug

The problem is that the existing ports of bjnp.exe are not compatible with rpm cups. I have got the rpm guys interested enough to want to know where they can download the bjnp source code so maybe we will get a port in the future. If lucky you will be able to test a known-to-be-working version in June  :-)

It may be possible to connect by USB - but totally impractical. The printer is about 15ft from the nearest system and router but in another room and would require around a 50ft usb lead.


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: Doug Bissett on April 25, 2017, 10:13:36 pm
Quote
I have got the rpm guys interested enough to want to know where they can download the bjnp source code so maybe we will get a port in the future. If lucky you will be able to test a known-to-be-working version in June  :-)

I believe that Paul Smedley did the current ports.

Quote
It may be possible to connect by USB - but totally impractical. The printer is about 15ft from the nearest system and router but in another room and would require around a 50ft usb lead.

It may be worth the effort to physically move it, to try USB. BJNP may not be the only problem. USB will be my backup plan, if BJNP won't work with my brother's printer.
Title: Re: configuring the rpm release of cups
Post by: Pete on April 26, 2017, 02:11:51 am
Hi Doug

Good thing you suggested trying the USB connection. The result is that usb/cups does not seem to be working, the cups browser interface does not offer to let me setup a local printer and Find Printers fails to discover the usb attached printer.

Opening a command prompt in usr/lib/cups/backend and entering usb results in the prompt returning with no information about a usb attached printer.

Yes, libusb10.dll is installed.

Yes, other usb devices, flash drive and mouse, work when plugged into the same usb port.

Guess I'd better report this failure as well.


Regards

Pete

Title: Re: configuring the rpm release of cups
Post by: Pete on April 26, 2017, 03:15:44 pm
Hi All

Does anyone have the rpm-cups working using a usb attached printer?

I ask because it seems I am not the only person reporting usb connectivity problems.


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: Pete on April 28, 2017, 06:38:09 pm
Hi All

I have discovered 1 source of USB printing problems here - wrong version of usbresmg.sys loaded in config.sys. Having changed the line to point to the latest version (Arca Noae 11.14) in \os2\boot and rebooted rpm cups now recognises the usb attached printer and allows me to create a new (usb attached) printer using the browser interface.

Sadly printing a Test page fails with the "filter failed" " gstoraster stopped with status 11" problem.

it seems a little strange that output should fail for what seems to be the same reason using 2 different output connections and makes me wonder if something that gstoraster relies on is not at the correct level.


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: Paul Smedley on April 29, 2017, 12:11:07 am
Hey Pete,

I have discovered 1 source of USB printing problems here - wrong version of usbresmg.sys loaded in config.sys. Having changed the line to point to the latest version (Arca Noae 11.14) in \os2\boot and rebooted rpm cups now recognises the usb attached printer and allows me to create a new (usb attached) printer using the browser interface.

Sadly printing a Test page fails with the "filter failed" " gstoraster stopped with status 11" problem.

it seems a little strange that output should fail for what seems to be the same reason using 2 different output connections and makes me wonder if something that gstoraster relies on is not at the correct level.

My personal opinion (having a little experience with cups) is that this is related to some changes that bitwise made to the cups code, to remove/modify some workarounds that I added for issues with select().

Your log shows that select() fails and suggests a retry will be attempted, but I don't see evidence in the logs of the retry attempt. I might be wrong of course, and I can't find the specific checking right now where they modified my original code....

Cheers,

Paul
Title: Re: configuring the rpm release of cups
Post by: Pete on April 29, 2017, 01:02:30 am
Hi Paul

If the rpm guys have roped in *the* OS/2 cups expert to help there must be a problem...  ;-)

I remember the frustration that problems with select() caused with the early cups ports. I do not remember if it affected all printers or just specific make/models - think I was running a Canon iP4000 then - but earlier in this discussion Doug reported a HP working fine with the ArcaOS installed cups.

I'm happy to test changes when ready - if you want debug2 logs posted to the netlabs bugtracker they will need to increase the size of file that can be uploaded as those logs can be around 600Kb.


Regards

Pete
Title: Re: configuring the rpm release of cups
Post by: Dave Yeo on April 29, 2017, 02:33:26 am
Hi Pete, try this version of libcx0.dll (backup your old one after unlocking), it has various select() fixes that I don't think have made it into an RPM yet.
Title: Re: configuring the rpm release of cups
Post by: Pete on April 29, 2017, 06:16:06 am
Hi Dave

It is certainly later and larger than the rpm packaged version. Sadly it does not resolve the gstoraster failure. It does increase the size of a debug2 log from around 600Kb to around 800Kb but does not tell me any more about the gstoraster failure.


Thanks

Pete
Title: Re: configuring the rpm release of cups
Post by: Pete on April 29, 2017, 05:47:10 pm
Hi Dave

Looking at the log again I do see a difference since updating the libcx0.dll

Previous logs have gstoraster reported as stopped  (logs from working non-rpm cups showed exited with no errors) before rastertogutenprint "exited with no errors":-

D [28/Apr/2017:17:01:07 +0000] [Job 1] Waiting for read thread to exit...
1045   D [28/Apr/2017:17:01:07 +0000] [Job 1] PID 129 (/@unixroot/usr/lib/cups/filter/gstoraster.exe) stopped with status 11.
1046   W [28/Apr/2017:17:01:07 +0000] cupsdDoSelect: select() returned -1... pause and retry select()
1047   D [28/Apr/2017:17:01:07 +0000] [Job 1] Read 512 bytes of back-channel data...
1048   D [28/Apr/2017:17:01:07 +0000] [Job 1] PID 130 (/@unixroot/usr/lib/cups/filter/rastertogutenprint.5.2.exe) exited with no errors.


Since the update the logs report that slightly differently:-

D [29/Apr/2017:03:39:45 +0000] [Job 1] Read 512 bytes of back-channel data...
d [29/Apr/2017:03:39:45 +0000] process_children()
d [29/Apr/2017:03:39:45 +0000] cupsdFinishProcess(pid=198, name=0x17f700, namelen=1024, job_id=0x17f6fc(1)) = "/@unixroot/usr/lib/cups/filter/rastertogutenprint.5.2.exe"
D [29/Apr/2017:03:39:45 +0000] [Job 1] PID 198 (/@unixroot/usr/lib/cups/filter/rastertogutenprint.5.2.exe) exited with no errors.
d [29/Apr/2017:03:39:45 +0000] cupsdFinishProcess(pid=197, name=0x17f700, namelen=1024, job_id=0x17f6fc(1)) = "/@unixroot/usr/lib/cups/filter/gstoraster.exe"
D [29/Apr/2017:03:39:45 +0000] [Job 1] PID 197 (/@unixroot/usr/lib/cups/filter/gstoraster.exe) stopped with status 11.


Based on all previous logs checked on all systems here the above looks wrong and seems to be a direct result of the libcx0.dll update.


Regards

Pete