[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Printing packaging rework 2020



Hello Till,

Le jeudi, 30 janvier 2020, 23.26:23 h CET Till Kamppeter a écrit :
> In general, printer drivers are supposed to be provided as Printer
> Applications from now on. I will do some Printer Applications for legacy
> printer drivers for Ubuntu in the next weeks, to be made available as
> snaps in the Snap store.

Would it be possible to make sure these are reasonably package'able as Debian 
packages?

> We need to ask some driver developers who maintain their drivers until
> now (HPLIP, Gutenprint, Ricoh PPDs, ...) whether there are relevant new
> models which need a driver or where printing with driver is highly
> recommended. Perhaps we ship only these driver packages by default then.

Do you have contacts to have that discussion with them? I don't really have 
the bandwidth, nor contacts.

> For the default config of cupsd, you suggest two versions: One only
> listening on the socket and therefore not sharing printers and not
> providing the web admin interface. Makes sense for desktops which are
> not sharing printers, they even do not need to share printers if all the
> available printers are network printers, and administration is done by a
> GUI app like GNOME Control Center or system-config-printer.

The problem I have come to understand is that CUPS' socket-activation 
implementation (either by the client, or by the server), doesn't work (with a 
socket readied by systemd, cupsctl fails to connect correctly). And fixing 
this needs active upstream work. I'm not upstream of CUPS for a good reason; 
and I don't have the energy/time/funding to go fix this.

So the plan as it seems, is going to be "cups permanently runs as daemon".

> We will need a running cups-browsed as long as print dialogs do not
> reliably display CUPS' temporary queues. As soon as they do so,
> cups-browsed is only needed for more sophisticated network printing
> configurations.

My plan was to leave cups-browsed indeed.

Cheers,
    OdyX

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: