On 20/4/09 23:36, Keith Seyffarth wrote: >> Googling that shows it to be a file shared with Windows boxes when you're >> running samba. I don't know if you set up samba or not, but I would ignore >> this error for now. It's likely unrelated to the printing problem that >> you're >> having. >> > > OK. Thanks. I guess. I was kind of hoping that figuring that out might > be the fix... > > >>>> Do you have the startup script: >>>> /usr/local/etc/rc.d/cupsd ? >>>> >>> yes >>> >>> >>>> If so, what is the output of /usr/local/etc/rc.d/cupsd status? >>>> >>> currently it's: >>> cupsd is running as pid 721. >>> >>> but I did start cups manually since my last reboot. >>> >>> >> Cupsd was started automatically on reboot by the script. So that part is >> working fine. >> > > after rebooting the machine, it's: > cupsd is not running. > > <config info snipped> > > >> It appears the problem is the printer. Try changing the perms to 0777 for >> testing purposes. If you're able to print, the problem is permissions. >> You'll >> have to figure out what permissions you need to get it working. >> > > That doesn't help. I get the same behavior with the permissions set to > 0777. > > >> One person mentioned that you should be using the ugen device instead of >> /dev/ultp0. This thread might be relevant - >> http://foo2zjs.rkkda.com/forum/read.php?9,546,547 >> >> You might have to abandon using cupsd for this printer. >> > > Yeah. We may not be using this printer long anyway, since it is nearly > out of ink, and the ink will be $95. It would just be nice to be able > to demonstrate that printing is an option. > > Also, from what I've been seeing in my testing and so on since > Thursday, it looks like if you use CUPS at all, you can't use anything > else, since CUPS overwrites things like /etc/printcap with its own > settings frequently. And since I've been successfully using cups-pdf > for several months, I'd need a replacement for that. At least with > that, despite all the shortcomings of .pdf format, we can still get > stuff printed. Just not in our office. > > >> If so, this might be helpful: >> http://www.onlamp.com/pub/a/bsd/2004/07/08/FreeBSD_Basics.html?page=last >> > > I had read through that several times. It is one of several places > pointing out that the device has to be at ultp*, and if it's at ugen* > you likely have a problem... > > However the pkg-message for hplip says differently. I had to recompile without ulpt in the kernel to get my hp c3180 psc to work, but it prints (and scans) fine from freebsd now. read the output from pkg_info -xD hplip It has got full instructions on what needs doing. Recompiling the kernel isnt actually all that hard, and is detailed fully in the handbook. Actually to any devs who might be reading, is there any reason we have ulpt built in rather than as a module?
Vince > _______________________________________________ > firstname.lastname@example.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" > _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"