[8145] in athena10
[Debathena] #1021: Will no one rid me of this turbulent LPRng?
daemon@ATHENA.MIT.EDU (Debathena Trac)
Thu Aug 4 16:21:33 2011
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@MIT.EDU>
Cc: debathena@mit.edu
To: geofft@mit.edu
Date: Thu, 04 Aug 2011 20:21:26 -0000
Reply-To:
Message-ID: <043.582e80772983f1665efc0b621c27450d@mit.edu>
Content-Transfer-Encoding: 8bit
#1021: Will no one rid me of this turbulent LPRng?--------------------+-------------------------------------------------------
Reporter: geofft | Owner:
Type: task | Status: new
Priority: normal | Milestone: The Distant Future
Component: -- | Keywords:
See_also: |
--------------------+------------------------------------------------------- Ops has turned off the LPRng servers. Per #465, we should stop supporting
the LPRng client, i.e., debathenifying it, including it, including
debathena-lprng-config, calling it from debathena-printing-config, and
enabling the LPR print dialog backend in the global gtkrc.
This is actually a bit tricky, though, because it is LPRng that we call to
print to non-Athena LPR printers: LPRng supports the lpr -Pqueue@host
syntax, and CUPS doesn't. (And CUPS would print over IPP instead of LPR
anyway.) And if we want to keep unpatched, unconfigured LPRng around, we
have a couple of issues: at least, LPRng likes to run a server by default,
which we disable, and it installs to /usr/bin/lpr etc., which we rename
out of the way in our rebuild so that it doesn't conflict with cupsys-bsd,
which we definitely want.
Another option would be to use a lightweight, serverless LPR-compatible
client like rlpr. Since it installs itself as rlpr, rlpq, and rlprm, there
aren't any filename conflicts. It seems to work in light testing; the only
real issue is that it displays "warning: cannot bind to privileged ports:
lpd may reject" all the time. It might be possible to suppress this in the
global rlprrc.
A similar option would be to take the Python code we started including in
debathena-printing-config's lpq to work around CUPS 1.3 issues, and extend
that to have lpr and lprm support. It's not like LPD is a hard protocol.
Still another option would be to figure out some way for CUPS to
dynamically use the lpd: backend without configuring a queue first. This
might actually be something we want to do to pull off some other ponies,
like entering a custom printer in the print dialog (see #465 and #378). We
currently do this with the LPR backend to gtk, which we'd like to get rid
of. Having the CUPS backend deal would be nicer.
Finally, we could decide that the upstream way and light is not to support
the lpr -Pqueue@host syntax, and have you create a new CUPS queue before
printing, and that if you really care you should just locally install rlpr
or something. (If go this route, I might be tempted to put rlpr in extra-
software or so.)
-- Ticket URL: <http://debathena.mit.edu/trac/ticket/1021>Debathena <http://debathena.mit.edu/>MIT Debathena Project
