CUPS 1.4.1 does not work

My T2 build has CUPS 1.4.1, but it does not recognise my USB printer.

I started earlier today to trace reasons why Woof builds are bigger than earlier puppies. I'm looking at the T2 build for now. The Ghostscript package for example is massive compared to the one in pup 4.3.1.

This lead me to testing printing, when I discovered CUPS won't recognise my printer. It doesn't recognise its existence. A quick search revealed this is a known problem:

http://bugs.archlinux.org/task/15998

The kernel 'usblp' module is no longer used, so I blcklisted it. But that did not help. The above link advises further changes, so I need to investigate further.

Sigh, CUPS is such a pain.

---

Comments

cups
Username: ttuuxxx
I fully agree Cups is a large pain, maybe one day you might make your own gui for printing and do away with cups? Would be nice to save the extra space etc. ttuuxxx

CUPS 1.4.2
Username: BarryK
"This may have solved some of the USB problems, but I don't have any confidence in it. On the otherhand, Patriot has done a lot of work getting earlier versions to work: http://www.murga-linux.com/puppy/viewtopic.php?t=40225 So I reckon I will roll back to CUPS 1.3.11 in my T2 build.

GlibC
Username: ttuuxxx
"Hi Barry, Have you tried compiling GlibC lately? When I try I keep getting an error, looked on the net and not much info on it. here's the error Go to the documentation of this file. DIS_IN_libpthread=1 -o /root/Downloads/glibc-2.10.1/compile/nptl/pthread_spin _lock.o -MD -MP -MF /root/Downloads/glibc-2.10.1/compile/nptl/pthread_spin_lock. o.dt -MT /root/Downloads/glibc-2.10.1/compile/nptl/pthread_spin_lock.o make[2]: *** No rule to make target `/root/Downloads/glibc-2.10.1/compile/nptl/p thread_spin_trylock.o', needed by `lib-noranlib'. Stop. make[2]: Leaving directory `/root/Downloads/glibc-2.10.1/nptl' make[1]: *** [nptl/subdir_lib] Error 2 make[1]: Leaving directory `/root/Downloads/glibc-2.10.1' make: *** [all] Error 2 # make[2]: *** No rule to make target `/root/Downloads/glibc-2.10.1/compile/nptl /pthread_spin_trylock.o', needed by `lib-noranlib'. Stop. > make[2]: Leaving directory `/root/Downloads/glibc-2.10.1/nptl' bash: command substitution: line 1: unexpected EOF while looking for matching `' also as patriots versions, hmmm last time I checked them, he leaves lots of open ports, Kind of a security risk. I usually only use your versions.

glibc
Username: BarryK
"ttuuxxx, I have only compiled glibc in T2. I'll upload all those binary packages soon. I have decided to test CUPS 1.4.2, compiling it in T2. Ha ha, it's 4am here!

cups 1.3.11
Username: BarryK
"I tried 1.4.2, still couldn't get it to recognise existence of my usb printer. I did everything recommended: blacklisted 'usblp' module, created an 'lp' group. I also created a udev rule as recommended on an Arch mail list, however that caused an error message at bootup. So, I have compiled CUPS 1.3.11, and that does recognise my USB printer. Yippee, except when I attempted to print a test page I got the famous "foomatic-rip failed" message.

glibC
Username: ttuuxxx
"great Barry looking forward to your glibc T2 package :) ttuuxxx

T2 build
Username: BarryK
"What I'm trying to do with the T2 build is come up with something that is as small as possible, with updated-but-well proven packages. I'm planning to do a recompile starting tonight or tomorrow, with some changes... I have rolled ghostscript back to espgs 8.15.4 (pup 4.3.1 has 8.15.2) -- reason, size, plus it works fine, although a bit old (late 2007). I'm thinking also of rolling xorg back to the latest files available in the xorg 7.3 series. I have asked kirk to help me there, as he has already gone down that track with T2. I'm undecided about GTK. ROX-Filer does not work properly with GTK 2.18.3, and I'm wondering if the problem that ROX is experiencing may affect other apps. I reported the bug to the ROX developers a couple of weeks ago, but they have shown no interest so far in tackling it. So, I'm seriously thinking of rolling back to GTK 2.16.x. Note, I'm mostly doing this T2 thing because I want a base for Quirky. I want it to be as small as possible and no hassles that we get with the bleeding edge packages (xorg 7.5, gtk 2.18 etc). Yet, do have most recent packages where they "just work" So far I've done the T2 build twice, each time it takes a couple of days. I have to keep my fingers crossed, the weather here is lots of little storms, high wind, and the power goes off.

GTK rollback
Username: BarryK
"When there is a new release of GTK, there are three packages, gtk+, glib and pango. I'm wondering if it is okay to leave glib and pango and only rollback gtk+? Oh yeah, and gtkmm also. I current have gtk+ 2.18.3, gtkmm 2.18.2, glib 2.22.2, and pango 1.26.0. So, I could rollback gtk+ to 2.16.6 and gtkmm to

PDQ printing
Username: BarryK
"Early versions of Puppy had PDQ, which is very nice, really tiny. It fell by the wayside for various reasons. No longer being developed. GTK 1.2 GUI application only. Some apps expect CUPS to be there. We could save an incredible amount of space with PDQ, plus it is very simple, and "just works". But, it would need someone who is able to commit to developing it. It is written in C. For a start, the GUI application would have to be rewritten for GTK2. Mandrake Linux used to use PDQ as the default printing system. Um, I can't recall what version was the last to do that... 8.x comes to mind. The thing is, those guys had developed PDQ to a high art, did very nice things with it. But, like all the other distros they dropped it and went for CUPS So, if anyone wanted to take on PDQ as a project, getting an old Mandrake distro would be useful. I don't recall the last version of Puppy that used PDQ -- it would be in my online blog archive.

PDQ
Username: ttuuxxx
"Hi BArry I downloaded the Mandrake sources that also contained 2 patches and patched the sources, then I compiled it, It fully compiled and well by clicking on the bins they wouldn't execute, probably because I don't have gtk1 installed, but If you ran them via the terminal, they worked, So I would think that probably a gui could be made to run the bins. Here's the sources http://c149.twaren.net/pub/Linux/Mandrake/old/8.1/SRPMS/pdq-2.2.1-8mdk.src.rpm here's the the bins running in the terminal [code] # /root/Downloads/pdq-2.2.1-i386/usr/local/bin/pdq Error. No printer specified, and no default printer defined. # /root/Downloads/pdq-2.2.1-i386/usr/local/bin/lpd_status Usage: /root/Downloads/pdq-2.2.1-i386/usr/local/bin/lpd_status [-l] [-v|-vv] queue@host | host [queue] -l to request a long listing -v to display warnings and fatal errors -vv to be annoyingly verbose # /root/Downloads/pdq-2.2.1-i386/usr/local/bin/lpd_print Usage: /root/Downloads/pdq-2.2.1-i386/usr/local/bin/lpd_print [-f file] [-j id_num] [-v|-vv] queue@host | host [queue] -f specifies data file (STDIN default) -j specifies job id (1-999, 001 default) -n do a "nasty" mid-send socket close on SIGTERM -v to display warnings and fatal errors -vv to be show simple status messages -vvv to be annoyingly verbose # /root/Downloads/pdq-2.2.1-i386/usr/local/bin/lpd_cancel Usage: /root/Downloads/pdq-2.2.1-i386/usr/local/bin/lpd_cancel -j id [-v|-vv] queue@host | host [queue] -j specifies id of job to cancel -v to display warnings and fatal errors -vv to be annoyingly verbose # [/code] ttuuxxx

gtk
Username: ttuuxxx
"2.14X uses ROX-Filer 2.9 libgtk-x11-2.0.so.0.1600.1 (2.16.1) libpango-1.0.so.0.2400.2 libpangocairo-1.0.so.0.2400.2 libglib-2.0.so.0.2000.2 They all work nicely together and have been well tested for 6+ months ttuuxxx

CUPS in Puppy
Username: nic2109
"It would be fairer to say "CUPS doesn't work in Puppy" than the sweeping statement that "CUPS 1.4.1 doesn't work". It works just fine for me in Ubuntu, and Mac OS. It would be very interesting if Pizzasgood could have a go at it in his multi-user puplet as my guess is that it's related to running as root. CUPS and other packages designed for the heavyweight distros assume: (1) that there are multiple users; and (2) that day-to-day operation is NOT done as root.

CUPS
Username: linuxcbon
"Why can't CUPS run as root ? If so then it's a bug.

CUPS as root
Username: nic2109
"I'm not saying that CUPS cannot run as root, but I am saying that it's been built with a "conventional" Unix setup in mind. And that convention is that there is a multi-user setup, with "ordinary" users running their day-to-day activites without root priviledges. Linux has merely followed suit as it were. Now we don't mind being root, but in the corporate/commercial/academic world they do mind very much so Unix and most Linux distros are set up with that in mind; and CUPS has followed that lead. I still think it's worth investigating - by someone who is more capable than your correspondent! Sorry.

CUPS as root
Username: me
"Cupsd runs as root in most distros.

CUPS as Root
Username: nic2109
""cupsd runs as root in most distros" Maybe, but why does Puppy struggle and (presumably) most distros do not? Barry spits and curses whenever dealing with CUPS, ttuuxxx and others have chipped in with improvements but it's still as friendly as a cornered ferret actually trying to use it in Puppy. For me it's simple and flawless in Ubuntu - just as it should be. So what's the difference? I know there's the size and Barry's constant search for smaller and simpler means that fat has been trimmed. Something in the fat might be the missing bit. But an architectural difference is our approach to who it is sending calls to cupsd. In Puppy it's root while in the others it usually isn't. It seems to me to be a possible candidate as part of the problem.

CUPS as root
Username: BarryK
"Other distros [i]do[/i] have trouble with CUPS. The first post has a link to Arch, where they have been struggling. What must not be overlooked is what distros the CUPS developers themselves use. If one or more of them uses Ubuntu, then of course they will make sure that all issues are resolved so that it simply works in Ubuntu. Then of course there are people who are experts in CUPS and know how to get it going on any distro. We do have our own expert, Patriot, who has been helping me in this situation, via pm's. It seems that USB support in CUPS 1.4.x is a mess. Patriot has advised me of one workaround to fix it. It is this kind of inside knowledge that other major distros will apply.

CUPS Developers
Username: nic2109
"Well; now that CUPS is owned by Apple, I imagine that the "raw" development is done under Mac OS and then ported to Unix and Linux. In Mac OS it is there but integrated, so it's harder to say what version it's at. It is operationally spot on and "just works" for both USB and Network printers. Apple did commit to keeping CUPS Open Source, but it does make the search for a working alternative attractive. No-one trusts a monopolist whether it comes from Redmond or Cupertino!

re cups and printing
Username: 8-bit
"Cups in Slacko and Lucid 520 finds my USB printers fine. In Slacko though I went to print a test page after installing my printer and it failed to print anything. I found that where I had NoScript installed in my browser, it was interfering with CUPS and a job was never created to pass to the printer. I allowed the CUPS browser page always for NoScript and the job got passed then and the printer worked.

Tags: woof