Custom Query (1145 matches)

Reported by jdreed, 14 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.

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

Reported by geofft, 14 years ago.

As pointed out by an OLC user, if I run emacs -e mh-smail, type in a message into the provided fields, and run C-c C-c to send the e-mail, I get

spost: -msgid unknown
send: message not delivered to anyone

We can either upgrade nmh to a version that supports the -msgid option (which adds a Message-ID: header to the outgoing mail), or wrap /usr/lib/debathena-nmh/spost to drop the -msgid option, or figure out how to make mh-smail not use the -msgid option.