[7000] in Release_7.7_team
Re: Maverick support
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Tue Oct 12 00:28:11 2010
Date: Tue, 12 Oct 2010 00:28:04 -0400 (EDT)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: Jonathan Reed <jdreed@mit.edu>
cc: release-team@mit.edu, debathena@mit.edu
In-Reply-To: <ABE09435-5EE9-4161-90F3-9698E6628EA1@mit.edu>
Message-ID: <alpine.DEB.1.10.1010120019030.7287@dr-wily.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 12 Oct 2010, Jonathan Reed wrote:
>
> On Oct 11, 2010, at 11:19 PM, Geoffrey Thomas wrote:
>
>> I intend to move Maverick's packages to production tomorrow morning
>
> A ~12 hour window on a holiday weekend for comment on a new release
> feels kind of short.
I sent mail Sunday night, and there was only one code change
(pam-config) that needed to be pushed, and my thinking is that it's a new
release so we're not risking destabilization of anything.
More importantly, Debathena will get uninstalled by people who run the
release upgrader unless the Maverick packages are in production and the
upgrader can upgrade Debathena at the same time (because of various
version dependencies on Lucid packages, probably libraries etc.), so I'm
leaning towards earlier rather than later.
>> enable maverick support in the installer shell script, and send mail to
>> this effect to debathena-announce and release-announce, assuming I
>> receive no reports of issues between now and when I wake up. Liz, Ben,
>> and I have all installed Debathena on Maverick and things seem fine.)
>
> 3 data points really doesn't feel like a good enough test of a brand new
> distro to me. I haven't even tested it yet. Also, which metapackages
> did you install? Did testing consist merely of installation, or
> anything else?
Up to workstation; tried logging in and poking around a bit and making
sure obvious stuff like AFS/zephyr/alpine/moira works. thirdparty and
cluster definitely don't work and I don't intend to support those except
possibly by coincidence when we work on the Natty cluster release.
>
> I think we need to start setting end-user expectations appropriately.
> Therefore, I would propose that until we get some additional testing,
> particularly of -workstation, I think that maverick support should be
> added to the installer as such:
>
> ===================================================================
> --- install-debathena.sh (revision 24892)
> +++ install-debathena.sh (working copy)
> @@ -187,6 +187,13 @@
> hardy|intrepid|jaunty|karmic|lucid)
> ubuntu=yes
> ;;
> +maverick)
> + output "Maverick is still undergoing additional testing, but is believed to"
> + output "be functional at this time. However, if this is a mission-critical"
> + output "workstation or production server, please proceed with caution."
> + output "If you encounter any problems during installation, please report"
> + output "them to debathena@mit.edu."
> + ubuntu=yes
> *)
> error "Your machine seems to not be running a current Debian/Ubuntu release."
> error "If you believe you are running a current release, contact debathena@mit.edu"
>
> This allows bleeding-edge users to install it immediately, but lets
> novice users know this may not be what they want. (Yes, I realize
> they've already installed Maverick by the time they run the installer,
> but still.)
I'd be fine with that, but it doesn't really cover the upgrade case, and
that's what I feel is more time-critical.
>> 1) There's an upstream bug in Maverick's libc apparently tickled by the
>> combination of nss_nonlocal being used and disabled by
>> $NSS_NONLOCAL_IGNORE that can cause cvs's postinst to crash when
>> creating /srv/cvs. The package manager reattempts the postinst and the
>> installation completes fine, but /srv/cvs is not properly created.
>> Since I'm not really aware of people using /srv/cvs as opposed to a
>> real repo somewhere else, and also since we can't fix this on our end,
>> I'm not considering this a blocker. The bug was fixed upstream shortly
>> after the release that Ubuntu took for Maverick, and Anders has filed
>> an Ubuntu bug at http://bugs.launchpad.net/bugs/658907 Because cvs has
>> not been updated in Ubuntu since Jaunty, this only affects new
>> installs.
>
> We should document this somewhere (i.e. Hermes).
>
>> 2) Upstream from now uses the "alternatives" system, so our diversion
>> of /usr/bin/from to install the one from mitmailutils may not take
>> effect. This only affects upgrades because with new installs, we
>> successfully divert the symlink to /etc/alternatives/from. On upgrades,
>> that symlink beats our symlink to from.debathena. I've filed a ticket
>> at http://debathena.mit.edu/trac/729 but the lack of "from" doesn't
>> particularly feel like a release blocker to me.
>
> I'm not really ok with this. "from" is in the default dotfiles, and
> users are going to notice those error out and ask OLC about it. It
> seems like it's probably a quick fix, and therefore we wouldn't be
> delaying the release by too long.
>
> I know we want to have Debathena out and supported as close to the
> release date as possible, but Debathena has much more exposure now, and
> we maybe need to sacrifice bleeding-edge support for a bit of polish.
I think I would be happier with Athena logins working and "from" not
post-upgrade, than Athena logins not working at all. :)
--
Geoffrey Thomas
geofft@mit.edu
