Package: xen-tools Version: 1.2-1 Severity: minor Recently I had some problems with how the /tls.disabled was created; I noted an upstream patch that had resolved the problems with creating a /lib/tls directory that could not be removed. I had made some debug to the script to try and figure out the problem in hook.d/10-disable-tls.
Later in the week, when the upgraded version with the patch was being deployed, I told apt to overwrite my 10-disable-tls script with the maintainers version. Unfortuately dpkg left the old buggy script at hook.d/10-disable-tls.dpkg-old as it normally does with any package update, where you accept the maintainers version. What happened next, is that xenu images created with xen-tools all still had the tls bug, as the .dpkg-old script was being executed, with the chmod 0 line that caused the initial problem. Long story short - The tls bug won't go away for anyone that has tinkered with their 10-disable-tls script. In fact the debconf upgrade procedure isn't really valid in this sort of rc-execute style hook.d directory. Is there a better approach? Can the .dpkg-old files be dumped in /etc/xen instead? No big deal for me, but I can see other users getting trapped without updates to the hook.d scripts due to the dpkg.old scripts being executed last after newer updates. cheers, iMac -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.12.6-xen Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages xen-tools depends on: ii debootstrap 0.2.45-0.2 Bootstrap a basic Debian system ii libterm-size-perl 0.2-1 Perl extension for retrieving term ii perl-modules 5.8.4-8sarge3 Core Perl modules -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
