Custom Query (1145 matches)


Show under each result:

Results (313 - 315 of 1145)

Ticket Resolution Summary Owner Reporter
#465 fixed come up with a coherent plan for debathena-printing-config geofft

Reported by geofft, 15 years ago.


Right now our lpr wrapper is a descendant of a descendant of a hack, solving lots of little use cases but with no particular overarching intention about what it's doing. While we shouldn't forget about the edge cases we're supporting and break them in a rewrite (cf. #455), it's about time to have a clear design and spec for what it's doing rather than continuing its descent into feature creep.

As I see it the two main issues with the current setup is that user-visible behavior depends on users being aware of whether a queue is CUPS and LPRng and that answering questions about the behavior usually requires looking at the source.

This includes: (some of the following are inspired by TODOs in the current printing-config lpr wrapper)

  • Should we support the traditional LPRng arguments that Athena's used for years, e.g., -Zduplex (ticket #444)? Forever?
  • Should we try to get these arguments upstream somehow, or is a cross-platform Athena lpr script that you can put early in your PATH sufficient? (Or do we not care for non-Athena platforms?)
  • Should the LPROPT environment variable be supported? Currently if you are printing to a CUPS queue, and if passed to lpr can be interpreted purely as CUPS arguments (such as if you just do lpr -Pfoo), then the arguments in LPROPT aren't inserted into the processed command-line arguments (see also  RT:1098339). We could desupport it, or support it all the time.
  • How do you default to double-sided printing, etc., for all queues? In theory LPROPT is an answer, but converting LPRng args to CUPS ones in perpetuity is silly and prevents you from actually specifying default CUPS arguments.
  • Are we keeping LPRng clients installed forever, or at some point will we say that if you want to print to an lpd printer, you should add a CUPS queue, and that Kerberized lpd printing is desupported (unless CUPS grows support for it)? (We can also keep the clients around while making lpr.debathena never call them.)
  • Are we keeping Hesiod pcap entries forever?
  • Are we keeping the "Print to LPR..." gtk backend forever? This saved me last week when some subtle BrowsePolling? bug caused only three faraway printers to show up in the pick list, but this is a config change from upstream and one that I think we intended to be temporary.
  • Can CUPS be made to zephyr (ticket #184)
  • Can CUPS be made to have an equivalent of -Zbanner=?
#468 fixed Can we drop a force-update and reconfigure-network script in /usr/share/recovery-mode/options/ ? jdreed jdreed

Reported by jdreed, 14 years ago.


/usr/share/recovery-mode/options is what gets presented to the user when they choose "recovery mode" at the grub menu. Hotline notes there's no way to force an update now.

Can we dump a shell script in /usr/share/recover-mode/options that forces an update and then a "real" reboot? (a kexec reboot occasionally will end up back in recovery mode, which is not what we want)

And when we have our debathena-change-the-ip-address-of-this-cluster-machine pony, that should go in the recovery-mode menu too.

I'll note that naming them "athena-update" and "athena-network" will cause them to appear at the top of the list (it's sorted alphabetically) which is desirable.

#470 fixed clear login screen state after a few minutes geofft

Reported by geofft, 14 years ago.


This may be a bit unrealistic, but then again, it might be trivial to implement.

I've seen users get confused when someone had previously (probably out of curiosity) picked a nonstandard window manager at the login screen and not logged in, so the next user ended up using that WM. Especially with WMs like twm or xmonad that default to a blank screen, this can be a pretty bad user experience. kchen also reports that the same thing is possible with languages -- someone can set a session language at the login screen and not log in, and the next user to log in will get prompted if they want that as their default language.

It would be nice, if possible, to cause that state to disappear if you haven't logged in after a minute or so; equivalently, that state should be made visible on the login screen, a la Athena 9's xlogin, and it should mention some easy way to clear it. (Does "Esc" work?)

This is probably not worth putting effort on for pre-Karmic gdm (i.e., <= 2.20).

Note: See TracQuery for help on using queries.