Author Topic: configuring the rpm release of cups  (Read 34038 times)

Pete

  • Hero Member
  • *****
  • Posts: 1294
  • Karma: +9/-0
    • View Profile
Re: configuring the rpm release of cups
« Reply #45 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

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: configuring the rpm release of cups
« Reply #46 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.

Pete

  • Hero Member
  • *****
  • Posts: 1294
  • Karma: +9/-0
    • View Profile
Re: configuring the rpm release of cups
« Reply #47 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


Pete

  • Hero Member
  • *****
  • Posts: 1294
  • Karma: +9/-0
    • View Profile
Re: configuring the rpm release of cups
« Reply #48 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

Pete

  • Hero Member
  • *****
  • Posts: 1294
  • Karma: +9/-0
    • View Profile
Re: configuring the rpm release of cups
« Reply #49 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

Paul Smedley

  • Hero Member
  • *****
  • Posts: 2095
  • Karma: +160/-0
    • View Profile
Re: configuring the rpm release of cups
« Reply #50 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

Pete

  • Hero Member
  • *****
  • Posts: 1294
  • Karma: +9/-0
    • View Profile
Re: configuring the rpm release of cups
« Reply #51 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

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4805
  • Karma: +99/-1
    • View Profile
Re: configuring the rpm release of cups
« Reply #52 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.

Pete

  • Hero Member
  • *****
  • Posts: 1294
  • Karma: +9/-0
    • View Profile
Re: configuring the rpm release of cups
« Reply #53 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

Pete

  • Hero Member
  • *****
  • Posts: 1294
  • Karma: +9/-0
    • View Profile
Re: configuring the rpm release of cups
« Reply #54 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