Package: aptitude
Version: 0.4.10-1+b2, 0.4.10-1+b1, 0.4.10-1
Severity: normal
When doing an interactive install or upgrade run (calling "aptitude"
without parameters), afterwards (e.g. after pressing "ugg<Enter>")
aptitude seems to have lost the connection to the tty or so.
Symptoms:
+ "Press return" to get back to the TUI still works.
+ When the TUI is back, no input is accepted anymore
+ Ctrl-C works and is also my workaround of choice.
+ After Ctrl-C all input (e.g. the "q" when you tried to quit) typed
since input stopped being accepted is found on the command line of
the shell in which I started aptitude.
I first had this problem on Debian GNU/kFreeBSD a while ago (first
with with aptitude 0.4.9 IIRC), but since Debian GNU/kFreeBSD has a
bunch of job control problems currently, I expected that it has
something to do with them and ignored it so far as following error.
But now it also appeared on Debian GNU/Linux.
Since I can't reproduce the problem on all machines, I initally
expected that it could have to do something with the environment, but
since "env -i TERM=$TERM aptitude" didn't change anything regarding
the problem, it probably is something different.
What I tested:
=====================
Doesn't work (hangs):
=====================
Linux on "loadrunner", i686, a recently from Etch to Sid dist-upgraded
machine. This is the host reporting the bug from (i.e. the System
Information is from this host), aptitude 0.4.10-1+b2, kernel
2.6.18-5-686.
+ via uxterm and ssh, LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8
(charmap=UTF-8, default locale)
+ local xterm, LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8,
default locale)
+ via xterm and ssh, LANG=en_US.ISO-8859-15 LC_CTYPE=C (changed in the
local shell using export)
+ via xterm and ssh, LANG=C LC_CTYPE= (changed in the local shell
using export)
+ via xterm and ssh, using "env -i TERM=xterm aptitude" (practically
no environment variables left)
GNU/kFreeBSD on "visa", i686, a long-running installation,
dist-upgraded every few days to weeks. On this host I noticed the
problem first with aptitude 0.4.9-something, currently running
aptitude 0.4.10-1 and kernel 6.2-1-686.
+ via uxterm and ssh, LANG=en_US, LC_CTYPE=
GNU/kFreeBSD on "c-metisse", amd64 inside QEMU/KVM, running aptitude
0.4.10-1+b1 and kernel 6.3-1-amd64-generic
+ via uxterm and ssh, LANG=en_US.UTF-8, LC-CTYPE=
==========================
Works fine (doesn't hang):
==========================
Linux on "kiva6", a Xen DomU, running Sid amd64 for months, updated
every few days, using aptitude 0.4.10-1+b1 and kernel
2.6.18-5-xen-amd64.
+ via xterm and ssh, LANG=en_US.ISO-8859-15, LC_CTYPE=C
Linux on "c-cactus" running amd64 Sid inside QEMU/KVM, updated every
few days to weeks, using aptitude 0.4.10-1+b1 and kernel
2.6.23-1-amd64.
+ via local xterm, LANG=en_US.UTF-8, LC_CTYPE=
So from these examples, to me it looks neither like a 32-bit-only or
kFreeBSD-only issue nor like a charset, environment or "ssh vs local"
issue. I currently just see no attribute which is only matching the
boxes where aptitude hangs.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-5-686 (SMP w/1 CPU core)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages aptitude depends on:
ii apt [libapt-pkg-libc6.7 0.7.10 Advanced front-end for dpkg
ii libc6 2.7-6 GNU C Library: Shared libraries
ii libcwidget1 0.5.6.1-3 high-level terminal interface libr
ii libgcc1 1:4.3-20080116-1 GCC support library
ii libncursesw5 5.6+20080119-1 Shared libraries for terminal hand
ii libsigc++-2.0-0c2a 2.0.17-2 type-safe Signal Framework for C++
ii libstdc++6 4.3-20080116-1 The GNU Standard C++ Library v3
Versions of packages aptitude recommends:
ii aptitude-doc-en [aptitude-doc 0.4.10-1 English manual for aptitude, a ter
ii libparse-debianchangelog-perl 1.1.1-2 parse Debian changelogs and output
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
