CUPS sucks!

[Helge Blischke]

ncoesel wrote:

>> On Aug 21, 2009, at 12:23 AM, ncoesel wrote:
>> > I've spend the last two days trying to get cups to work on an
>> > embedded platform.
>>
>> Um, CUPS is currently not supported on any embedded platforms,
>> although I do know of several people playing with it there.
> 
> Huh??? Linux is linux. No matter what the platform is! You're probably
> referring to Linux distributions. The difference between distributions
> (paths & users) is usually covered by the automake/autoconf settings.
> 
>> > The major problem I'm experiencing is that Cups provides no
>> > diagnostic information at all so I don't know what I must fix.
>>
>> You mean cupsd was not generating an error_log file listing the errors
>> it found?
> 
> I've set the level to debug2. But it is not generating meaningfull errors.
> I'd expect if it finds a USB device port but can't access it, it reports
> an error in the log. The software I write does stuff like that and also
> provides hints to fix problems.
> 
>> > It appeared my lp0 device had insufficient rights. Doesn't say in
>> > the documentation, I had to visit the links in 3 pages of Google
>> > results before I found an obscure forum that gave a hint towards the
>> > rights.
>>
>> The required permissions vary based on the Linux distribution you run;
>> we don't document distribution-specific stuff...
>>
>> > Now I still need to solve an 'Unsupported format' problem.
>>
>> Sounds like you may want to enable raw printing - look at the
>> mime.types and mime.convs files included with CUPS.
> 
> Sorry to be rude but 'Sounds like' isn't good enough for me. I want to
> know exactly why CUPS is giving me 'unsupported format'. Which programs it
> is trying to run (including paths and arguments), where parsing of a
> config file goes wrong, etc. According to internet forums there are
> several possible causes for the 'Unsupport format' error. The logfile
> should contain crystal clear information on what is causing the problem.
> 
> Some software actually provides the source file and line number of a
> problem when the log level is set to debug. The C/C++ macros __FILE__
> (string) and __LINE__ (integer) can be used to generate this information
> so there is at least a possibility to trace the error by looking at the
> source (this is not an ideal solution ofcourse).
> 
>> > Guys (and girls), this really needs fixing!
>>
>> *What* needs fixing? Supporting embedded platforms? Documenting every
>> platform's idiosyncrasies? Making the existing documentation more
>> visible?
> 
> Cups should provide meaningfull errors and warnings to start with. For
> example the usb program. When I run it, it detects the printer just fine.
> When I run Cups, Cups can't detect te printer and doesn't generate any
> error or warning. This could be fixed by having Cups or the usb program
> report 'usb printer device found with insufficient rights' (or something
> like that).
> 
>> > The commands like lpstat, cupsd have no help to show the options (--
>> > help) or to show the version (--version).
>>
>> There is a pending feature request for this; in short, we never
>> implemented these options because they are not standard for those
>> commands  and we have extensive help (http://localhost:631/help) and
>> man page coverage.
> 
> --version is pretty standard. Perhaps on Windows you'd like something like
> /?. Anyway, it is a good custom to have some option that prints at least
> the version. What if you have two versions of Cups installed? How do you
> know which one is running? Which one is started when cupsd is started from
> the command line? We have quite a lot of systems in the field and there is
> no way to keep them at the same version. So being able to obtain version
> information is a first priority. Don't assume the man or the manual is
> installed on the system.

Perhaps you could supply a sample error_log to look into in order to deal
with your complaints?

Helge