Custom Query (1145 matches)

Reported by jdreed, 15 years ago.

We need to inventory the WRW apps, and determine how they print. The goal is to figure out:

• If they use GTK or Java
• if they allow a user to specify a command line (and if so, is it lpr or lp)
• if they hardcode any paths to printing commands
• what their default output format is (PDF, PS, etc).
• anything else we think is relevant.

Going forward, we come up with a set of guidelines, and new 3partysw on Athena has to conform to those guidelines (maybe to the point where a program cannot be installed on Athena if it hardcodes /usr/bin/lp).

Note that this will be difficult, because we need to look at both the Ubuntu packages and any locker software.

If we encounter printing stupidity in Ubuntu packages, we should be sure to file a bug upstream.

Reported by broder, 15 years ago.

Apparently the BSD-style commands (lpr, lpq, lprm, lpc) are being phased out with CUPS in favor of the SysV-style commands (lp, lpstat, cancel, etc). If that's the case, we're probably going to want to eventually transition to teaching and using the SysV commands, which means they're going to need to be able to deal with our multi-server configuration.

Specifically, we probably want to add wrapper scripts for:

• cancel
• lpstat
• lpoptions
• accept
• reject
• cupsaccept
• cupsreject
• lpmove
• cupsenable
• cupsdisable

We probably don't care about wrapper scripts for:

• cupstestdsc
• cupstestppd
• cupsaddsmb
• lppasswd
• lpadmin
• cupsctl
• lpinfo

Reported by jdreed, 15 years ago.

When we switched to a 6-hour desync schedule during busy periods, we lost the ability to push out updates quickly. I think we want this back, particularly if we break printing again.

While the existing desync intervals (6 hours "during the day", 2 hours otherwise) are fine as fallbacks, I want the auto updater to go check a URL for a suggested desync interval. If fetching the URL fails, it can fallback to the existing schedule. We undoubtedly want to take #309 into account when implementing this.

Alternatively, the only real reason we want to desync updates is to avoid the suckage of huge updates (texlive, OOo, etc). We had talked about a URL providing a whitelist of packages that should be updated immediately, so that we can fix, say, reactivate and printing-config instantaneously. The danger there is that we can also deploy broken packages instantaneously.

This description should be updated to reflect whichever method we chose for regaining some measure of control over auto-updates.