Custom Query (1145 matches)

Reported by jdreed, 13 years ago.

We don't import preseed.common for vanilla installs, but probably should, since it includes things like d-i mirror/country string manual

But it also runs the postinstall script. So we should either split .common out into something like .common and .really-common, or the postinstall should check for a pxetype of "vanilla" and exit 0.

Reported by geofft, 13 years ago.

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.)

Reported by geofft, 13 years ago.

That "Welcome to Debathena" is split across the monitors is the most glaring bit. Possibly the little infobox at the bottom right identifying the machine's version should also be on the primary monitor. The actual login dialog is correctly centered on the primary monitor.