Trying to get CUPS to work
Topic: Trying to get CUPS to work
started by: Juanito
Posted by Juanito on June 09 2007,13:14I've been struggling for a while to get CUPS to work with a HP OfficeJet G85 connected via USB directly to my machine.
1. If I use cups.unc everything appears to set up OK. I chose a Deskjet 900 series driver as per the hplip site on Sourceforge and tried a test page. The test page print job apparently completes OK, there are no error message, but nothing prints.
2. If I use apt-get to install hplip from oldstable, I can use some of the utilities to check that my printer is seen OK:
If I set CUPS up with this URI and try to print a test page, the print job comes up as cancelled and I get the following error message from /var/log/cups/error_log:
I [09/Jun/2007:16:48:02 -0400] Job 3 queued on 'OfficeJetG85' by 'root'.
E [09/Jun/2007:16:48:02 -0400] Unable to convert file 0 to printable format for job 3!
I [09/Jun/2007:16:48:02 -0400] Hint: Do you have ESP Ghostscript installed?
I [09/Jun/2007:16:48:02 -0400] Hint: Try setting the LogLevel to "debug".
Ghostscript was installed via apt-get hpijs, but just to make sure, I downloaded and compiled the espgs-7.07.1 binary with the same result.
Ha anybody seen the same problem?
Posted by Juanito on June 11 2007,13:22Attacking this from a different angle, I compiled the following:
The compile competes OK, does not complain about anything missing and the CUPS browser-based set up goes OK.
When I try to print a test page to a different printer (HP OfficeJet K80 via USB) it doesn't work and I get these error messages:
CUPS browser interface
"open print channel failed; will retry in 30 seconds..."
user.err hpiod: unable to read MlcReverseReply header: Resource temporarily unavailable bytesRead=0 io/hpiod/mlc.cpp 237
user.info hpiod: invalid MLCInitReply retrying command... io/hpiod/mlc.cpp 345
user.err hpiod: unable to read MlcReverseReply header: Resource temporarily unavailable bytesRead=0 io/hpiod/mlc.cpp 237
user.err hpiod: invalid MLCInitReply: cmd=0, result=3 , revision=40 io/hpiod/mlc.cpp 355
user.warn OfficeJet_K80?serial=ES0911401VOH: INFO: open print channel failed; will retry in 30 seconds...
Posted by ^thehatsrule^ on June 11 2007,15:32Is foomatic* installed? Though "Resource temporarily unavailable" doesn't seem good...
Posted by Juanito on June 24 2007,10:05In fact foomatic wasn't installed so I compiled it, but still could not print - both cups and hplip seem to be poor at stating what exactly is required for them to work.
I had a minor breakthrough yesterday in that I managed to print a test page - in two years of using DSL, this is the first time I managed to get anything out of a printer...
Here's the list of debs I installed from oldstable (in that order):
debconf, ucf, libjpeg62, libpaper1, libc6, libssl, libsnmp-base, libsensors3, libsnmp5, libncurses5, libreadline4, libdb4.2, zlib1g, python2.3, python, libtiff4, libpng12-0, libslp1, xpdf-common, libgcc1, gcc-3.3-base, libstdc++5, xpdf-utils, libaudio2, libexpat1, libfontconfig1, liblcms1, libmng1, libxrender1, libxcursor1, libqt3c102-mt, xlibmesa-glu, python2.3-sip4-qt3, python2.3-qt3, python-qt3, libgpg-error0, libgcrypt11, liblzo1, libopencdk8, libtasn1, libgnutls11, libcupsys2-gnutls10, libcupsimage2, patch, libgdbm3, perl-base, perl-modules, perl, libusb-0.1-4, usbutils, defoma, libgimpprint1, gsfonts, gs-common, gs-gpl, gs, libglib2, gs-esp, cupsys, hplip-data, hplip, cupsys-client, cupsys-bsd
Again, there are several debs that are required that are not mentioned in the list of dependencies for hplip.
Apart from the test page (only from cups, not from hp-testpage), I could not get anything else out of the OfficeJetG85 - I tried to print from Firefox but got an error about gtk and widgets(?). Using an OfficeJetK80 I did not get any errors but also did not get any test page or other print.
Can it really be so hard to print (and this is without speaking of faxes or scanning)?
Posted by curaga on June 24 2007,10:46Does printing the unix way work?
eg echo "Testing printing" > /dev/lp0 or whatever the printer is?
Posted by curaga on June 24 2007,10:54After checking the HP site I know why you first didn't get it working:
Minimum HPLIP version for officejet g85 is 0.9.5 and debian oldstable has 0.9.2..
No idea why the one you compiled didn't work. But did the unix way work?
Posted by Juanito on June 24 2007,13:20
I didn't think of that, but:
I'll try to compile hplip-0.9.5 over the top of the oldstable install and see what happens.
Posted by curaga on June 24 2007,14:04The unix way should always work..
The fact that nothing happened with /dev/usb/lp0 might say you need a newer kernel..
But try 0.9.5 first
Posted by Juanito on June 26 2007,11:10So, compiling hplip-0.9.5 over the top of the deb installation didn't work, but I seem to have had more success leaving hplip-data and hplip out of the deb installation and then compiling hplip-0.9.5 - this required the following "header debs" before the compile would configure:
libc6-dev, libjpeg62-dev, libtiffxx0, zlib1g-dev, libtiff4-dev, libpng12-dev, libopencdk8-dev, libtasn1-2-dev, libgpg-error0, libgpg-error-dev, libgcrypt11-dev, libgnutls11-dev, libcupsys2-dev, libcupsimage2-dev, libsnmp-perl, libwrap0, libwrap0-dev, libssl-dev, libsnmp5-dev, python2.3 & python-dev
"./configure" and "make" completed without errors but "make install" halted with this error:
The error notwithstanding, using an HP OfficeJetK80 connected via usb I was able to print a test page - both from cups and using hp-testpage - and, finally, was able to print the cups-admin page and a 2MB jpeg from Firefox.
I guess more investigation is needed to understand why the compile failed and then build an extension/figure out which files need to be added to my backup (I saw Roberts listed these for cups in a post, but I believe more/different ones may be needed with hplip).
Anyway - thanks for the pointers, I seem to be on the right track.
Posted by Juanito on June 28 2007,04:00I found a small application - chkconfig-1.3.30a.tar.bz2 - that cures the "make install" error allowing hplip-0.9.5 to compile and install properly. A while ago there was a post (< see here >) about the < http://localhost:631 > connection being refused due to the cpu being too busy after starting the cupsys daemon - this happened to me with an extension I made from the 1st compile attempt and appears to have been cured by using chkconfig in the second compile attempt.
Whilst I can compile hplip and print without problems, I am still unable to print using an extension made from the compile - furthermore, I can only compile from a legacy boot - the hplip "make install" fails whilst copying ppd files on a normal boot.
Maybe the cups installation is machine specific - I compiled on a legacy boot machine, made a unc extension and loaded it on another machine - the quest to make printing/faxing/scanning work continues...
Posted by Juanito on June 29 2007,11:32I'm still struggling with this - I can print reliably after compiling/installing hplip but I cannot print after making an extension out of hplip. I tried two methods:
1. Install a number of debs using dpkg and compile hplip-0.9.5 and make an extension from the files installed. When I load the extension after reboot and try to install a printer, things go OK up until I give the printer a name in the cups admin client and then I get this message:
2. Install a number of debs using dpkg and compile hplip-0.9.5 and install a printer (works OK) and make an extension out of the files installed. When I load the extension after reboot and try to print a test page I get this message:
Does anybody have an idea what the problem might be?
Posted by ^thehatsrule^ on June 29 2007,21:45When I used to print from my "brother" printer, I did not use cups (they have some great native linux drivers), but my only problem was permission on the temporary printer spool. Searching around seems to suggest this as well for cups... in "/var/spool/cups". You might have to manually create it? (maybe easier to just archive it)
Did you try
Posted by Juanito on June 30 2007,04:36If I understand corectly, you're suggesting to change the permissions on /var/spool/cups to dsl/staff, is that correct?
I'd love to set the log level to debug, but how?
Posted by ^thehatsrule^ on June 30 2007,06:51
Posted by Juanito on June 30 2007,10:16Thanks - once I changed the log level to debug in /etc/cupsd.conf, I saw this:
Creating an empty directory /var/spool/cups/tmp solved the problem - you'd think cups would be smart enough to write it's own /tmp directory...
Now I can restore an extension on my laptop and get things working. I thought his was fixed, but when I load an extension on my ancient desktop and start the cupsys daemon, the cpu usage goes to 100% and never returns (even if I stop cupsys) and thus the connection to < http://localhost:631 > is refused...
Got it - deleting the cups and hplip files in /etc/rc0.d - /etc/rc6.d seems to have stopped the 100% cpu thing.
But only in dsl format, a unc made from the dsl gives the same "connection refused" error - I guess that'll have to do for now.
Posted by ^thehatsrule^ on July 03 2007,01:02Since you are required to have a empty directory, make sure you that you create your extension manually (that includes that empty dir) and that you do _not_ run the declobber script at all. Then converting it should be fine.
If it still doesn't work, then check if that tmp directory exists after loading the unc. If it's not there, maybe there's a bug?
Posted by Juanito on July 03 2007,03:34In fact to avoid the declobber problem, I did the following:
I was wondering if it was the cpu overhead of using a unc that caused the problem, although even the dsl version stops working after 30mins or so...
Posted by ^thehatsrule^ on July 03 2007,04:04I think you meant "mkdir /var/spool/cups/tmp"?
Can you manually write to .../tmp after the unc in loaded? I seem to remember some problems with dirs...
For now (for the unc) you could just write a post mydsl-load script that does "mkdir -p /var/spool/cups/tmp" (and take out any other dirs related to that in the extension)
What do you mean by it "stops working" after a while... any errors/messages, or does it just abruptly stop working? Maybe try removing the temp dir and trying again?
I think we should clear up the doubts on what to do when one does need a empty directory in an extension, because if placing an empty "placeholder" file in it will become standard, perhaps adding it to the declobber script can account for empty directories. But this may be out of the topic's scope.
Posted by Juanito on July 23 2007,05:39I'm back working on this again using later versions of cups/hplip and compiling all of the various dependencies (jpeg, openssl, net-snmp, etc) from scratch.
In contrast to my last attempts, cups now seems to work and carry on working (by "stops working" in the above, I meant that the cpu utilisation goes to 100% when trying to print and nothing prints) but hplip will not work.
Since hplip requires python in order to compile and run, I used Roberts python.uci extension (which loads to /opt/python) then symlinked the headers to /usr/include and added /opt/python/bin to the path - ./configure picked up the location of python (I checked the Makefile to confirm this) and the compile completed to /opt/hplip without errors.
When I try to use the various hplip functions (cups will print, but I need hplip for fax and scanning) like hp-probe, hp-levels, etc which are symlinks to *.py files I get the error "/usr/bin/env python: no such file or directory". Note that "env python" starts python without errors.
Using Google brought up all sorts of discussions about changing "#!/usr/bin/env python" in the first line of *.py files but I don't think this is the problem. Both /opt/python/bin and /opt/hplip/bin are in the path - does this need to be set globally in DSL maybe? I'm guessing that python cannot find the *.py files in /opt/hplip/share/hplip but if I cd to that directory it doesn't help.
Any suggestions would be welcome.
Posted by ^thehatsrule^ on July 23 2007,17:07
Posted by Juanito on July 23 2007,18:43Thanks - I tried a symlink in /opt/bin but got the same result...
Posted by Juanito on July 26 2007,19:01Got it:
This function is particularly DSL - pity you can't see the lurid colour
Posted by Juanito on July 27 2007,11:43...Not such a breakthrough as I originally thought. Now I can get print output in the following ways:
1. "Print Test Page" button in cups admin
2. $ hp-testpage -p OfficeJetG85
3. $ lp -d OfficeJetG85 Events
Note that /opt/hplip/bin is first in $PATH from the terminal window.
However I cannot print from Beaver, Ted, Firefox, etc - if I try from Beaver, I get this:
Posted by lucky13 on July 27 2007,12:09Did you edit the config files for those apps to use the paths you're using? See ~/.beaver/General for its print command. I don't know about Ted and I don't see an rc file for it. Maybe print to file and then print the file?
Posted by Juanito on July 27 2007,12:20I guess I could edit the config files, but I would need to do that for all of the DSL apps I'm likely to print from. I was more looking for some way to globally modify the DSL path so that all apps and terminal windows would use the modified path.
Posted by lucky13 on July 27 2007,14:30
That's why all those ./rc files are there. An alternative is to print from command line.
You can also make drag and drop scripts -- use DSL 4's ability to drag and drop for tasks like that. Make one executable script to print a file, even associate an icon for your printer on your desktop. Drag files to it to print the files.
Posted by ^thehatsrule^ on July 27 2007,16:35looks like it tried to connect to a lpd... I think theres lpd included in DSL you could try starting... (DSLPanel?)
Posted by Juanito on July 27 2007,17:14I'm pretty sure that the issue is /usr/bin/lp and /usr/bin/lpr - if I delete them and replace them with the following symlinks:
/usr/bin/lp -> /opt/hplip/bin/lp
/usr/bin/lpr -> /opt/hplip/bin/lp
Then I can print from various apps without problems, what I'd like to do (rather than this blunt instrument solution) is have DSL search /opt/hplip/bin before /usr/bin on a global basis rather than just from a terminal window.
Posted by curaga on July 28 2007,06:48umm, why is replacing those two files a bluntier solution than editing PATH in bashrc/bash_profile?
Posted by Juanito on July 28 2007,09:56Where would you put an "export PATH=" statement in .bashrc/.bash_profile? I don't see any references to the path in those files on my machine...
Posted by curaga on July 28 2007,11:01in /etc/bashrc, the global system file
Posted by Juanito on July 28 2007,12:19Thanks - should've thought of looking there
I'm getting close to being able to post an hplip extension (cups-1.2.11, hplip-2.7.6) - I was thinking to post the extension in several parts, does this make sense:
1. hplip.tar.gz - the main programs (cups, espgs, hplip), libs, foomatic, fonts, etc
2. python.uci - v2.3.6 with the latest security updates
3. hplip_etc.dsl - conf files to be loaded once to /etc then added to backup
4. hplip_ppd.tar.gz - ppds to be loaded once then appropriate printer(s) added to backup
5. site-packages.tar.gz -files shared by hplip & python
The locations of the files would be /opt/hplip, /opt/python & /opt/site-packages - once tested, hplip & site-packages could also be uci extensions.
Posted by stupid_idiot on July 28 2007,13:10Hello Juanito:
Do you think my 'MyDSL->Testing->python2.5.uci' could do the job?
It is using an idea similar to yours - mine is using '/opt/py25/site-packages' instead of '/opt/site-packages'. Reason is because some python packages want to have '/opt/py25/include' or /opt/py25/share'. Anyway, that is the technical issue. The non-technical issue is that I thought '/opt/site-packages' might conflict with other python uci's - maybe people will want to make uci's for python 2.3 or 2.4.
I am saying this because I think you will run into the same problem.
If this post seems very rude to you, please forgive me. I do not mean to say that you 'should not' make another python extension. Only, to avoid confusion, I would like to suggest - maybe name it 'python2.3.uci'?
Thank you very much.
Posted by Juanito on July 28 2007,15:05
I believe hplip would compile different *.py files against Python-2.5 and I also believe the location of Python might be hardcoded in hplip.
As you say, having the extension use /opt/python2.3 and /opt/python2.3_site-packages or similar would probably make more sense - I'm not sure I can face recompiling things at the moment though...
Posted by Juanito on July 30 2007,16:03
Posted by curaga on July 30 2007,16:18might be.. How about adding something like this to bootlocal.sh:
Posted by kuky on Aug. 23 2007,12:14for newbes..
1) hplip runs ?
if yes how in a easy language...
Posted by ^thehatsrule^ on Aug. 23 2007,17:58kuky: as always, read the .info first