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
signature.asc
Description: This is a digitally signed message part.
