Bug#218131: glibc: LSB test failures tcgetattr
Package: glibc Version: 2.3.2-9 Severity: serious On both i386 and ia64 the LSB tests, /tset/POSIX.os/devclass/tcgetattr/T.tcgetattr tests 1 and 2 fail. The source for these tests is available at, http://cvs.gforge.freestandards.org/cgi-bin/cvsweb.cgi/tests/lsb-runtime-test/m odules/vsx-pcts/tset/POSIX.os/devclass/tcgetattr/?cvsroot=lsbonly_with_tag=lsb -runtime-test-1_3_6 These tests do not fail on woody but do on sarge and sid. See, http://lists.debian.org/debian-lsb/2003/debian-lsb-200310/msg00027.html (note it may be due to the patches listed in that message) Additional information on Debian and LSB is available at, http://people.debian.org/~taggart/lsb/ If you need any help solving this, like installing the tests or testing fixes, please let me know. Because LSB compliance is considered release critical this bug is being filed as serious. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218129: glibc: LSB test failure vfprintf
Package: glibc Version: 2.3.2-9 Severity: serious On ia64 the LSB test, /tset/LI18NUX2K.L1/base/vfprintf/T.vfprintf test 5 fails. The source for the test is available at, ttp://cvs.gforge.freestandards.org/cgi-bin/cvsweb.cgi/tests/lsb-runtime-test/mo dules/li18nux2k.l1/tset/LI18NUX2K.L1/base/vfprintf/?cvsroot=lsbonly_with_tag=l sb-runtime-test-1_3_6 Additional information on Debian and LSB is available at, http://people.debian.org/~taggart/lsb/ If you need any help solving this, like installing the tests or testing fixes, please let me know. Because LSB compliance is considered release critical this bug is being filed as serious. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218130: glibc: LSB test failure fwide
Package: glibc Version: 2.3.2-9 Severity: serious On ia64 the LSB test, /tset/LI18NUX2K.L1/base/fwide/T.fwide test 4 fails. The source for the test is available at, http://cvs.gforge.freestandards.org/cgi-bin/cvsweb.cgi/tests/lsb-runtime-test/m odules/li18nux2k.l1/tset/LI18NUX2K.L1/base/fwide/?cvsroot=lsbonly_with_tag=lsb -runtime-test-1_3_6 Additional information on Debian and LSB is available at, http://people.debian.org/~taggart/lsb/ If you need any help solving this, like installing the tests or testing fixes, please let me know. Because LSB compliance is considered release critical this bug is being filed as serious. Thanks, -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debian lists UNSUBSCRIBE
ladies and gentlemen, please unsubscribe me from ALL Lists!!! i missjudged the amount of email i would be getting. (about 500 per day!!) thank you very much willy steimel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3 glibc LSB RC bugs filed
Hi, At Wed, 29 Oct 2003 01:13:08 -0800, Matt Taggart wrote: I just filed 3 RC bugs against glibc for the following LSB test failures, #218130 ia64: /tset/LI18NUX2K.L1/base/fwide/T.fwide 4 FAIL #218129 ia64: /tset/LI18NUX2K.L1/base/vfprintf/T.vfprintf 5 FAIL #218131 ia64/i386: /tset/POSIX.os/devclass/tcgetattr/T.tcgetattr 1 FAIL ia64/i386: /tset/POSIX.os/devclass/tcgetattr/T.tcgetattr 2 FAIL and I added them to the LSB bug page at, http://bugs.debian.org/cgi-bin/lsb.cgi Please see the bugs for more info. More Debian/LSB info at http://people.debian.org/~taggart/lsb/ I looked at your bug report, but I can get info about FAIL, so I pulled files from cvs, but I could't test because we need to make LSB test suite. Could you prepare complete source tarballs to test them for us (because http://people.debian.org/~taggart/lsb/ test suites are link missing), or inform us where the probelm is? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#204789: ia64 function descriptors and unexec
Greetings! I've added Bdale and emacs-devel to the CC list, as I believe they have already found some work around for gnu emacs, a description of which would help me greatly. To sum up the previous discussion, the ia64 linux ABI apparently offers no opportunity for ld.so to ensure that function descriptors remain constant, even over successive executions of the same binary on the same machine. Any unexec'ed image which has saved function pointers in its .data section will therefore likely be corrupt on re-execution, as the saved function descriptors, even when simply referring to functions in the same program, will likely not correspond to the freshly allocated new ones. I believe that this issue stood in the way of an emacs port to ia64 linux for some time, and that Bdale contributed a fix, but I can't find it in the archives or in the current source. GCL's best bet now appears to be to implement this work around if possible, and if not, to try to find and dump the old ld.so function descriptor table into the saved image at unexec time. Help much appreciated! A few other comments below: Daniel Jacobowitz [EMAIL PROTECTED] writes: On Tue, Oct 28, 2003 at 11:49:38AM -0500, Camm Maguire wrote: Greetings, and thank you so much for your reply on this issue! Please let me preface the below with the statement that these are, of course, my opinions only, and that there may well be issues of which I'm unaware which may contraindicate my conclusions. Briefly, I think this is a bug in libc6 because: 1) It makes stable unexeced binary images, to my understanding, impossible. Unexecing has never, however, worked portably. I think emacs even moved away from it, though I'm not sure of that. To my knowledge, emacs still uses unexec. Xemacs uses something else. base, I cannot find it. I've had a helpful suggestion from a reader of debian-ia64 that I should modify the gcl's unexec to dump the portion of the descriptor table containing internal function addresses into the image itself as a runtime override of ld.so's work, but this appears both desperate and fragile. The alternatives are also desperate and fragile. That at least limits the damage to gcl. Fair enough. Didn't know how bad those suggestions would be vis a vis libc6. 2) ld.so's changing of the function descriptor table is (apparently) unnecessary, albeit possibly permitted by the ABI. To my knowledge, the Debian port to hppa faced similar issues, yet the implementation arrived at is free of this problem. In addition, the same helpful respondent referred to above suggested three ways in which this problem could be addressed at the ld.so level: The way that hppa does this is, I think, very different. Two of the Do you mean the ABI is different, i.e. does provide an opportunity to ensure constant function descriptors? To my knowledge, hpux on this hardware has the same issue, yet (Debian) linux is free from it. suggestions below require substantial changes to the static linker and some fudging with the ABI. Using sbrk would probably not solve the issue at all. I understand that such changes may be inadvisable due to the scope of both the work required and the functionality affected, but, hypothetically speaking, would such an implementation once achieved 1) still conform to the ABI, 2) operate stably, and 3) be arguably preferable from a design standpoint? For the sake of the new readers, these suggestions were: = If this analysis is correct, I suspect there are multiple ways to fix the problem: - One possibility might be to have the link editor reserve the necessary space so that make_fptr_table() can map this reserved space, rather than allocating anonymous memory via mmap(). Downside: requires changed to both the link-editor and the runtime loader and I'm not sure how the runtime loader would locate the reserved-space section. - Another possibility might be to change make_fptr_table() to use sbrk() instead of mmap() when it allocates the descriptor table for the main program. Downside: I'm not sure it's safe for the runtime loader to change the process' break-value. - A third possibility might be to materialize function pointers for the executable program at link time (rather than at load time). I think the ELF symbol resolution rules would allow that, but I'm not sure whether it would be easy to make these descriptors visible to shared objects. Hmmh, none of these look terribly attractive to me. Richard, what do you think? = 3) The ld.so ia64-specific behavior is clearly the root of the tree of these problems, and is the logical place to address them all once and for all. And, unless the ABI
Processed: Re: Bug#217329: glibc-doc: references and errno values not conforming to standard in pthread_* function manpages
Processing commands for [EMAIL PROTECTED]: tag 217329 moreinfo Bug#217329: glibc-doc: references and errno values not conforming to standard in pthread_* function manpages Tags were: sid Tags added: moreinfo thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#204789: ia64 function descriptors and unexec
Camm Maguire [EMAIL PROTECTED] writes: To sum up the previous discussion, the ia64 linux ABI apparently offers no opportunity for ld.so to ensure that function descriptors remain constant, even over successive executions of the same binary on the same machine. There is no problem with statically initialized function pointers, only for assigned pointer at runtime. The function descriptors for the former are generated at compile time and won't ever change. I believe that this issue stood in the way of an emacs port to ia64 linux for some time, There is no such problem with GNU Emacs. Only XEmacs has this problem. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec
Greetings, and thanks for your reply! Andreas Schwab [EMAIL PROTECTED] writes: Camm Maguire [EMAIL PROTECTED] writes: To sum up the previous discussion, the ia64 linux ABI apparently offers no opportunity for ld.so to ensure that function descriptors remain constant, even over successive executions of the same binary on the same machine. There is no problem with statically initialized function pointers, only for assigned pointer at runtime. The function descriptors for the former are generated at compile time and won't ever change. OK, but I need saved runtime-initialized function pointers. Do you have either a reference for how xemacs has handled this, or a contact person who might know? Was there ever a GNU emacs obstacle on ia64 linux, or am I confusing the situation with xemacs? Take care, I believe that this issue stood in the way of an emacs port to ia64 linux for some time, There is no such problem with GNU Emacs. Only XEmacs has this problem. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Gcl-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/gcl-devel -- Camm Maguire[EMAIL PROTECTED] == The earth is but one country, and mankind its citizens. -- Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#217355: acknowledged by developer (fixed)
On Sun, Oct 26, 2003 at 08:48:32PM -0600, Debian Bug Tracking System wrote: This will be fixed with tomorrow's mirror pulse, with libc6 2.3.2-9 Thank you. BTW, I am curious how it is possible. Please, correct me, if I am wrong. There is one source package: glibc. This package is passed to builder (human or robot, no difference for this analysis). If everyting is OK some binary packages are build. If any error occurs... well, there are two cases. 1. Compilation error. It stops process, we have no binary packages. 2. Package build error. It stops process, but is is possible that some debs are created. There are not signed and (I suppose) not accepted by katie. In both cases we have none binary packages. This bug, however resolved, is weird for me. Could anyone explain me this behavior or point me a mistake in my reasoning? Thanks for your attention. Cheers Artur -- Dopty dysk dane nosi, pki mu bootsector nie padnie /z pamitnika administratora/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#217355: acknowledged by developer (fixed)
On Wed, Oct 29, 2003 at 06:30:35PM +0100, Artur R. Czechowski wrote: On Sun, Oct 26, 2003 at 08:48:32PM -0600, Debian Bug Tracking System wrote: This will be fixed with tomorrow's mirror pulse, with libc6 2.3.2-9 Thank you. BTW, I am curious how it is possible. Please, correct me, if I am wrong. There is one source package: glibc. This package is passed to builder (human or robot, no difference for this analysis). If everyting is OK some binary packages are build. If any error occurs... well, there are two cases. 1. Compilation error. It stops process, we have no binary packages. 2. Package build error. It stops process, but is is possible that some debs are created. There are not signed and (I suppose) not accepted by katie. In both cases we have none binary packages. Architecture: all packages such as locales are only built on one architecture, but used by all architectures regardless of whether the rest of the source package has been built for them. This saves all the build daemons having to build identical packages. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#217355: acknowledged by developer (fixed)
On Wed, Oct 29, 2003 at 06:16:18PM +, Colin Watson wrote: Architecture: all Uh, I missed it. Thank you. Cheers Artur -- * Croolik jest dzielna, zeara 3 zby. /stosowana medycyna naturalna/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218131: 3 glibc LSB RC bugs filed
On Wed, 2003-10-29 at 04:13, Matt Taggart wrote: #218131 ia64/i386: /tset/POSIX.os/devclass/tcgetattr/T.tcgetattr 1 FAIL ia64/i386: /tset/POSIX.os/devclass/tcgetattr/T.tcgetattr 2 FAIL In reference to that bug, the following mailing list messages might be useful: http://sources.redhat.com/ml/libc-alpha/2003-02/msg00117.html http://sources.redhat.com/ml/libc-hacker/1998-12/msg00076.html Upon closer analysis, it would seem that the current behavior is slightly more correct than the behavior in woody, but still not 100% correct. Roland McGrath, in a followup to the former message, is partially right. The patch introduced in the latter message is incorrect when it reports any kernel jiggering of c_cflag to be incorrect. However, removing the patch entirely is also incorrect. In glibc as delivered, setting PARENB alone on a pty will return success, which is also incorrect according to Roland. (I haven't looked at what POSIX really says yet.) So it would seem that we need to restore the old patch, but modify it to only trigger if no valid settings are changed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[BUG] syscall wipes pthread's thread internal info, broking pthread_cancel and other funcs
Hello!
I've found a bug in GNU libc-2.3.2 on Linux - i386 platform. I'm trying to
work with threads, sometimes it is needed to quickly (without reaching a
cancellation point) stop a thread. I've used pthread_cancel function but it
doesn't work in the following example:
#include pthread.h
#include unistd.h
#include sys/stat.h
#include unistd.h
#include fcntl.h
void* bug (void *t)
{
int fd;
int a;
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, 0);
fd = open(/dev/zero, O_RDONLY);
printf(opened fd = %d\n, fd);
close(fd);
while (1) {
a++;
}
}
int main()
{
pthread_t th;
int retval;
pthread_create(th, 0, bug, 0);
usleep(10);
pthread_cancel(th);
pthread_join(th, retval);
}
Further investigations shows that close() function is written as assembly
macro, defined in linuxthreads/sysdeps/unix/sysv/linux/i386/sysdep-cancel.h.
If pthread is available, macro defines to the following:
CENABLE
SAVE_OLDTYPE_##args
PUSHARGS_##args
DOCARGS_##args
movl $SYS_ify (syscall_name), %eax;
int $0x80
POPARGS_##args;
POPCARGS_##args
cmpl $-4095, %eax;
jae SYSCALL_ERROR_LABEL
If syscall has one paramers (as in case of close), value returned from CENABLE
(which is defined to call __pthread_enable_asynccancel) will be overwritten
in the next statements. This result in calling __pthread_disable_asynccancel
call with wrong parameters. All this things broke cancel handling in thread
structure, preventing pthread_cancel from work.
My system:
[EMAIL PROTECTED] alex]$ dpkg -l |grep libc6
ii libc6 2.3.2-9GNU C Library: Shared libraries and Timezone
ii libc6-dbg 2.3.2-9GNU C Library: Libraries with debugging symb
ii libc6-dev 2.3.2-9GNU C Library: Development Libraries and Hea
With best regards,
Alexander Vodomerov.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec
Camm Maguire [EMAIL PROTECTED] writes: OK, but I need saved runtime-initialized function pointers. Do you have either a reference for how xemacs has handled this, or a contact person who might know? I have hacked XEmacs to re-assign all those function pointers, good enough to get it running. But this hack is too ugly, so I never bothered to send the patch upstream (I also never used XEmacs myself, so I don't care much). I've heard that the current version of XEmacs use a different dumper which doesn't have this problem any more, but I didn't test it yet. Was there ever a GNU emacs obstacle on ia64 linux, or am I confusing the situation with xemacs? Since GNU Emacs does not assign function pointers at runtime there was never such a problem. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving glibc out of unstable
On Tue, Oct 28, 2003 at 11:37:46AM -0500, Daniel Jacobowitz wrote: [...] What do we need to do to get the other translations updated? in debian/po : grep ^\Last-Translator: *po | cut -f3 -d\:| sed 's/\\n\//' Will give you the mail addresses of translators. Then mail them the corresponding po file If it's filled in. Which it isn't for three of the six out-of-date translations. [...] I just mailed translators listed into es.po, nl.po, pt_BR.po and ru.po. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec
Andreas == Andreas Schwab [EMAIL PROTECTED] writes: Andreas Camm Maguire [EMAIL PROTECTED] writes: Andreas I have hacked XEmacs to re-assign all those function Andreas pointers, good enough to get it running. But this hack is Andreas too ugly, so I never bothered to send the patch upstream (I Andreas also never used XEmacs myself, so I don't care much). I've Andreas heard that the current version of XEmacs use a different Andreas dumper which doesn't have this problem any more, but I didn't Andreas test it yet. Well the version packaged for Debian on IA64 still does not work: Bug #149088 in the debian bug tracking system. Peter C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec
Peter Chubb [EMAIL PROTECTED] writes: Andreas == Andreas Schwab [EMAIL PROTECTED] writes: Andreas Camm Maguire [EMAIL PROTECTED] writes: Andreas I have hacked XEmacs to re-assign all those function Andreas pointers, good enough to get it running. But this hack is Andreas too ugly, so I never bothered to send the patch upstream (I Andreas also never used XEmacs myself, so I don't care much). I've Andreas heard that the current version of XEmacs use a different Andreas dumper which doesn't have this problem any more, but I didn't Andreas test it yet. Well the version packaged for Debian on IA64 still does not work: Bug #149088 in the debian bug tracking system. You can get a picture of the necessary changes from ftp://ftp.suse.com/pub/suse/i386/8.2/suse/src/xemacs-21.4.12-39.src.rpm. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218081: [peterc@gelato.unsw.edu.au: Bug#218081: libc6 2.3.2-9 won't install]
Daniel == Daniel Jacobowitz [EMAIL PROTECTED] writes:
Daniel Meant to copy yo on this, Peter. Adam suggests checking the
Daniel output of lsattr. If you can repeat this, strace output of
Daniel dpkg would be nice too.
The root filesystem is reiserfs.
lsattr /lib/ld-2.3.2.so
s---c ld-2.3.2.so
And this is the relevant part of strace output:
...
[pid 1280] utime(/lib/ld-2.3.2.so.dpkg-new, [2003/10/30-10:28:13,
2003/10/27-13:34:17]) = 0
[pid 1280] link(/lib/ld-2.3.2.so, /lib/ld-2.3.2.so.dpkg-tmp) = 0
[pid 1280] rename(/lib/ld-2.3.2.so.dpkg-new, /lib/ld-2.3.2.so) = -1 EBUSY (
Device or resource busy)
[pid 1280] write(2, dpkg: error processing libc6_2.3..., 138dpkg: error proce
ssing libc6_2.3.2-9_i386.deb (--install):
unable to install new version of `./lib/ld-2.3.2.so': Device or resource busy
) = 138
[pid 1280] lstat64(//lib/ld-2.3.2.so.dpkg-tmp, {st_mode=S_IFREG|0755,
st_size=92174, ...}) = 0
[pid 1280] rename(//lib/ld-2.3.2.so.dpkg-tmp, //lib/ld-2.3.2.so) = 0
[pid 1280] rmdir(//lib/ld-2.3.2.so.dpkg-new) = -1 ENOTDIR (Not a directory)
[pid 1280] unlink(//lib/ld-2.3.2.so.dpkg-new) = 0
I note that /lib/ld-2.3.2.so.dpkg-tmp is left behind after the process
completes, too.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218081: [peterc@gelato.unsw.edu.au: Bug#218081: libc6 2.3.2-9 won't install]
On Thu, Oct 30, 2003 at 10:38:57AM +1100, Peter Chubb wrote:
Daniel == Daniel Jacobowitz [EMAIL PROTECTED] writes:
Daniel Meant to copy yo on this, Peter. Adam suggests checking the
Daniel output of lsattr. If you can repeat this, strace output of
Daniel dpkg would be nice too.
The root filesystem is reiserfs.
lsattr /lib/ld-2.3.2.so
s---c ld-2.3.2.so
Do those mean the same things they do on ext2? If so, they're zero
when deleted and transparent compression. Bizarre.
This sounds like a kernel bug, not a dpkg or libc bug.
And this is the relevant part of strace output:
...
[pid 1280] utime(/lib/ld-2.3.2.so.dpkg-new, [2003/10/30-10:28:13,
2003/10/27-13:34:17]) = 0
[pid 1280] link(/lib/ld-2.3.2.so, /lib/ld-2.3.2.so.dpkg-tmp) = 0
[pid 1280] rename(/lib/ld-2.3.2.so.dpkg-new, /lib/ld-2.3.2.so) = -1 EBUSY (
Device or resource busy)
Rename is not documented as returning EBUSY normally. Investigate why
this happened.
[pid 1280] write(2, dpkg: error processing libc6_2.3..., 138dpkg: error proce
ssing libc6_2.3.2-9_i386.deb (--install):
unable to install new version of `./lib/ld-2.3.2.so': Device or resource busy
) = 138
[pid 1280] lstat64(//lib/ld-2.3.2.so.dpkg-tmp, {st_mode=S_IFREG|0755,
st_size=92174, ...}) = 0
[pid 1280] rename(//lib/ld-2.3.2.so.dpkg-tmp, //lib/ld-2.3.2.so) = 0
[pid 1280] rmdir(//lib/ld-2.3.2.so.dpkg-new) = -1 ENOTDIR (Not a directory)
[pid 1280] unlink(//lib/ld-2.3.2.so.dpkg-new) = 0
I note that /lib/ld-2.3.2.so.dpkg-tmp is left behind after the process
completes, too.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218081: [peterc@gelato.unsw.edu.au: Bug#218081: libc6 2.3.2-9 won't install]
Peter == Peter Chubb [EMAIL PROTECTED] writes: Daniel == Daniel Jacobowitz [EMAIL PROTECTED] writes: Daniel Meant to copy yo on this, Peter. Adam suggests checking the Daniel output of lsattr. If you can repeat this, strace output of Daniel dpkg would be nice too. I think I've worked out the problem. I have the lsbdev package installed, which mounts --bind /lib/ld-2.3.2.so into /var/lib/lsbdev/root/lib/ld-2.3.2.so So it looks as if there's an incompatibility between lsbdev and standard library upgrading. Peter C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218081: [peterc@gelato.unsw.edu.au: Bug#218081: libc6 2.3.2-9 won't install]
reassign 218081 lsbdev thanks Yes, I agree. On Thu, Oct 30, 2003 at 11:01:10AM +1100, Peter Chubb wrote: Peter == Peter Chubb [EMAIL PROTECTED] writes: Daniel == Daniel Jacobowitz [EMAIL PROTECTED] writes: Daniel Meant to copy yo on this, Peter. Adam suggests checking the Daniel output of lsattr. If you can repeat this, strace output of Daniel dpkg would be nice too. I think I've worked out the problem. I have the lsbdev package installed, which mounts --bind /lib/ld-2.3.2.so into /var/lib/lsbdev/root/lib/ld-2.3.2.so So it looks as if there's an incompatibility between lsbdev and standard library upgrading. Peter C -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: move to lsbdev
Processing commands for [EMAIL PROTECTED]: reassign 218081 lsbdev Bug#218081: libc6 2.3.2-9 won't install Bug reassigned from package `libc6' to `lsbdev'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
