reassign 321717 glibc 2.3.5-1 reassign 321718 glibc 2.3.5-1 reassign 321720 glibc 2.3.5-1 reassign 321721 glibc 2.3.5-1 reassign 321723 glibc 2.3.5-1 reassign 321724 glibc 2.3.5-1 merge 321718 321717 321720 321721 321723 321724 severity 321718 important thanks On Sun, Aug 07, 2005 at 02:56:10AM -0400, Joe Mason wrote: > (so far I've found libgcrypt, libcrypto, and libelf, and I'm filing bugs > for all of them). I'd rather you hadn't. None of these libraries are buggy. In the future, it would be appreciated if you would open a single bug report describing your issue, and let the developers sort out where the problem lies. > Package: upgrade-reports > Severity: critical > I just did a dist-upgrade, and every time I try to run a program linked > with libacl (which includes mv, cp, and ls) I get the following error: > error while loading shared libraries: libacl.so.1: cannot enable > executable stack as shared object requires: Error 14 > This makes the entire system unusable. This error message originates with glibc, and appears to be new as of glibc 2.3.5. Your reportbug-generated dependency lists confirm that this is the version you're running. So this bug, such as it is, belongs to the glibc package; I've reassigned accordingly. However, it's also apparent from the system details in your report that your system is in an unsupported state: > Google suggests this has something to do with "pax", which I've never > heard of and have certainly never installed or enabled. > -- System Information: > Debian Release: testing/unstable > APT prefers stable > APT policy: (500, 'stable') > Architecture: i386 (i686) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.4.18-bf2.4 > Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Setting aside the oddity of your apt configuration here, it's evident that you've tried to upgrade your system to current Debian unstable while running a kernel from *woody*. It is the policy of the Debian release team that direct upgrades from woody to etch will not be supported, and this is an interesting example of why that policy is warranted. There have been no other reports of this problem even though glibc 2.3.5 has been in preparation for some time, and I have at least one system that is running glibc 2.3.5 successfully with a 2.4.27 kernel from sarge, so apparently this is an incompatibility that only exists between pre-sarge kernels and glibc 2.3.5. It should be straightforward for you to fix your system by installing a 2.4.27 kernel from sarge and rebooting the machine, which is the supported upgrade path in any case. This means the bug should not be considered critical; I've downgraded it accordingly. It is still important that the glibc package be fixed, so that it does not permit installation on an unsupported kernel. This has been done in the past for select architectures, but it seems we now have a reason to bump the requirement across all architectures, which should give the glibc team a nice clean start (and a nice clean preinst) for etch. :) Thanks, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature