[cups.general] Cups

[Bernd Schubert]

Michael Sweet wrote:

> Bernd Schubert wrote:
>> ...
>> May I kindly ask for better debugging support in cups? I already wrote
>> once to cups.development how I think cups log messages should look like,
>> unfortunality I never got a response.
> 
> I never saw the message.
> 
> Quick response after looking at the archived message: the kind of
> message grouping you are looking for is not feasible given that the
> multiple jobs can be printing at the same time and the volume of
> messages is not limited.

Well, I guess adding the job-id before every message would be the easiest
part, wouldn't it?

If someone seriously wants to debug a single messages he probably wouldn't
print several jobs at once, at least I wouldn't do that ;) 

So why not?:

----Processing print job xyz--------------
job-id: writing file abc.ps given as lpr option to /var/spool/cups/tmp/xyz
job-id: ps2ps 'all given options' xyz xyz.ps2ps
job-id: gs 'all given options' xyz.ps2ps xyz.gs
job-id: pstoraster 'all given options' xyz.gs xyz.pstoraster
job-id: pstoraster terminated with non-zero exit code: def
trying to continue
job-id: next_command 'all given options' xyz.pstoraster xyz.next_command
job-id: next_command terminated with non zero exit code: ghi
job-id: Detected twice a non-zero exit code, aborting. The failling command
was probably pstoraster. You can keep the temporary files in debug level 2
---End of print job xyz -----------------




> 
> That said, the current format would allow for a filter based on the
> job ID to extract only those messages which are associated with a

By adding the job id before every message a filter program still should
work.

> job to provide much the same output you are looking for, and then
> a little software analysis could tell you the probable cause of the
> failure.  The (free) ESP Log Viewer software on our main site
> ("http://www.easysw.com/printpro/", then follow the links) is an
> initial effort towards doing just that - it can determine many
> common problems with a click of a button.

Thanks a lot, I didn't know about this program.

[snip]

> 
> Well, given that all/most of the Debian developers are volunteers
> and may not have access to the resources needed to help you, why
> do you expect them to help you or be able to help you?

Thats the way debian works. A debian developer maintains a package and users
submit bugreports using the "reportbug" program or directly send a mail to
him. The least I would expect is an answer, even if it says that he has no
clue about the reason. We all hope that Debian Sarge is to be released
soon, but how should it ever become released if known critical bugs are not
fixed. Since I didn't know that all Epson inkjet printers are effected and
since I also posted a workaround, I only submitted it as non release
critical.

> 
>> ...
>> Another funny story is that the cups http configuration frontend doesn't
>> list all drivers. For the epson stylus C82 only the non-working
>> (Cups+gimprint) driver is listed, but not the working driver
>> (foomatic+gimprint-ijs). Without the kde-printing manager I even wouldn't
>> have known about the other driver, since even its ppd is not listed at
>> linuxprinting.org.
> 
> Well, if the PPD file is there, then it will be listed by the web
> interface.  I don't know if the Foomatic drivers are installed via
> PPD files or through some other means (I don't use it, personally),
> however if they aren't using the standard CUPS mechanisms to list
> drivers then shame on them...

Indeed, I was just searching my harddisk for those ppd's and I can't find
them. Is there a way to create this on the fly, where should I ask about
it? Linuxprinting.org?

> 
> As for the difference, CUPS+Gimp-Print and Foomatic+gimpprint-ijs
> should be using the same Gimp-Print drivers (one linked to CUPS
> as rastertoprinter and one links to the IJS stuff and used through
> Ghostscript...)  All I can guess is that you are not using a version
> of Ghostscript that has been compiled with CUPS support.
> 

Which ghostscript would that be, /usr/bin/gs or /usr/bin/gs-esp?


Thanks for your help,
        Bernd