[7579] in Release_7.7_team
Test cupsys-config 1.14 (need override for cluster-cups-config 2.0.4)
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Sat Jul 30 12:30:32 2011
From: Jonathan Reed <jdreed@MIT.EDU>
Content-Type: text/plain; charset=us-ascii
Date: Sat, 30 Jul 2011 12:30:25 -0400
Message-Id: <BD13F7E8-8E2D-4A84-8898-B326E0FCED1D@mit.edu>
To: release-team@mit.edu
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Transfer-Encoding: 8bit
The Pharos transition is currently sheduled for Monday. It is imperative that cupsys-config 1.14 (currently in -development) gets some testing.
The following testing has already been done by me. It would be great if the results could be verified.
- take cupsys-config 1.14 via auto update on -cluster: succeeds if nobody has logged in to machine, fails if there has been at least one login -- see below
- fresh installed on a natty cluster machine (via PXE): succeeds
- take cupsys-config 1.14 via auto-update on workstation: succeeds
There is a problem with taking the package via auto-update on cluster (specifically, machines that have cluster-cups-config installed). We don't restart cups outside the chroot (when someone has logged out). Arguably this is a bug. Additionally, aptitude does not invoke cluster-cups-config's prerm as "remove in-favour blah blah", instead just as "remove". So the prerm gets called, but it fails, because cups isn't running outside the chroot (except between first boot and first login). And require_cups in configure-athena-printers doesn't correctly start cups ($rcname status will always return 0 in an upstart world, so that block doesn't run). I think the best way to deal with this is to quickly push out a new cluster-cups-config with the corrected require_cups block, and I'd like to do that today so that machines take it before we push out cluster-cups-config.
TL;DR I want to push cluster-cups-config 2.0.4 (currently in -dev, where it probably doesn't play nice with cupsys-config) to production now and plan to do so unless I hear objections. There's still the possibility that some machines will fail to update in time, but they'll also be taken care of when we go to natty.
-Jon
