[1780] in athena10
proposed report: 3/19/09
daemon@ATHENA.MIT.EDU (Evan Broder)
Thu Mar 19 19:46:28 2009
Message-ID: <49C2D908.6040107@mit.edu>
Date: Thu, 19 Mar 2009 19:45:12 -0400
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: debathena@mit.edu
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
A quick tour through what's currently in -proposed (I'm defining
"tomorrow" to be "tomorrow between noon and 3 PM" so it's not "5 PM on a
Friday"):
* barnowl: I don't know of any outstanding issues with this package
(1.1-2debathena1 includes a cherry-pick of commit 18105584, and is based
on Sam's 1.1-3).
Plan: move to production tomorrow
* debathena-alpine-config: There is a potential issue for Hardy users.
If a Hardy user has -backports enabled, and has marked alpine as
manually installed, the new debathena-alpine-config will cause some
unhappy prompts from aptitude. It'll either try to remove
debathena-alpine-config (see new debathena-clients) and upgrade alpine
to 2.00, or it will explicitly require the user to accept holding alpine
at its current version.
Hardy users who run into this can work around it by running "aptitude
install alpine&M", at which point aptitude will mention that it's
holding the alpine package back, but won't require explicit user input
anymore. I suspect that most users will have alpine pulled in
automatically, so they won't run into this at all.
This seems acceptable, especially given that we seem to be making good
progress on getting krb5 support on the mail servers (which will
eliminate the need for debathenifying alpine in the first place), so I
don't actually see any good reasons to hold off on moving this package.
Plan: move to production tomorrow
* debathena-clients: Changes (debathena-alpine-config | pine) to be a
recommendation, at the same time that debathena-alpine-config depends on
debathena-alpine instead of recommending it.
Plan: move to production tomorrow (whenever debathena-alpine-config
hits production)
* debathena-reactivate: This enables the very verbose logging for
reactivations. It's been in place for a while now, and doesn't seem to
have exploded yet.
Plan: move to production tomorrow
* debathena-thirdparty-{languages,libraries}: These fix up dependencies
that have either been removed, renamed, or replaced in Ubuntu. I don't
disagree with anything in these changes.
If you want to see the changes, you can do that by cd'ing into
/mit/debathena/apt/pool/debathena/d/debathena-thirdparty-{libraries,libraries}
and running `debdiff *.dsc` (yes, I'm an awful person, but it does work :-P)
Plan: move to production tomorrow
And that's everything that I think is ready to go into production.
What's left:
* debathena-firefox-wrapper: I'll let Bob make the call on this one.
* debathena-cluster-login-config: This contains patches to enable
kexec-tools, which supposedly will close ATN-52. It seems to work on
opus, and it definitely makes rebooting faster. I'm in favor, but would
like to hear confirmation that it actually closes ATN-52 before moving
it into production
Plan: blocking on feedback from someone with a Dell 745
* libpam-krb5-config: Someone with a Jaunty -login or -workstation
machine should verify that the package in -proposed works
Plan: blocking on feedback from Jaunty debathena-login or
debathena-workstation
* debathena-login-graphical, debathena-login-workstation: We need to
hammer out the language on the notice to debathena-announce. We should
also incorporate a statement about Dapper into that e-mail before
sending it. I'll put this about halfway down the list of things I intend
to look at next week.
Plan: blocking on finished notice to debathena-announce
* debathena-xdsc: I don't like this patch, because it feels like it's
failing to understand the underlying problem. However, nobody seems to
be interested in writing a better patch, so I'm inclined to go with
memory leaks over crashing.
Plan: move to production on Monday, to give any interested parties
time to write a better patch
And that's everything.
Comments are welcome.
- Evan
