incorrect printers on CUPS screen

[Dave White]

Use HPLIPS toolbox to install HP960C printer. Start up CUPS. Go to CUPS admin screen. It indicates 2 new printers were found (CANON and EPSON) on the same port used by the HP printer.

[Dave White (db-white)]

Screen shot

[TomasHnyk (sup)]

Does the HP960C work? Otherwise, I am afraid this is default behaviour for any printer, at least it works the same way on my side but it does not cause any troubles and I can print however I please. (I guess it circumvents inability of cups to detect epson or canon printers attached via parallel, but that is only my guess)

[Dave White (db-white)]

The HP960C works, it's just disconcerting that the graphics on the Admin page are out of sync. It makes it look like the software doesn't know what it's doing...

[glandux (glandux)]

I have the same behaviour with CUPS. There is no trouble with this.
HPLIP is not responsible of this behaviour. A quick search leads me to files /usr/lib/cups/backend/epson and /usr/lib/cups/backend/canon which belong to cupsys-driver-gutenprint package containing CUPS drivers. I don't think this is abnormal if you have a parallel port.

[TomasHnyk (sup)]

I am afraid this is a feature and not a bug, sorry. If you disagree, feel free to reopen the bug.

[Pascal De Vuyst (pascal-devuyst)]

From /usr/share/doc/cupsys-driver-gutenprint/README.gz:
    * Back ends for driving Canon and Epson printers, named "canon"
      and "epson". These provide the ability to get information from
      the printer for CUPS to use, and are normally installed in
      /usr/lib/cups/backend.

I have the same with my HP DeskJet 3820 printer.
I agree we should not see CANON or EPSON printers being found by CUPS if there is no Epson or Canon printer connected, which is the case for my HP printer.

Reopening this bug as either a cupsys or gutenprint issue.

[Till Kamppeter (till-kamppeter)]

This is clearly an upstream problem of Gutenprint. The Gutenprint backends should read out the device ID to check whether the extra functionality of the backends applies to the actually installed printers and if no suitable printer is installed the backends should not produce any output when called without arguments (so that they do not produce a line in "lpinfo -v".

[Till Kamppeter (till-kamppeter)]

Reported upstream to Gutenprint developer mailing list (gimp-print-devel at lists dot sourceforge dot net).

[Till Kamppeter (till-kamppeter)]

I have done a bug report in the upstream bug tracker now:

http://sourceforge.net/tracker/index.php?func=detail&aid=1893173&group_id=1537&atid=101537

[Till Kamppeter (till-kamppeter)]

Does the problem still occur with an up-to-date Hardy?

[wolfger (wolfger)]

Marking as "fix committed" since upstream is "fix released" (but that isn't showing in Launchpad). Relevant comment from upstream is:

Looking at the source code, I can see how 5.0.0 would do this, but this
was fixed between 5.0.0 and 5.0.1 -- specifically, after 5.0.0.99.1, which
is the version Ubuntu seems to have used at some point