$B=O=w$+$*$j$N!H$*$9$9$a!I(B$B$h$s!*!*(B

[$B$+$*$j(B]

$B=O=w!!$+$*$j!!$N!!!H$*$9$9$a!I!!$h$s!*!*(B  
$B$"$J$?$N9%$_$N=w@-$r>R2p$7$^$9(B
$BB>$K$bA49q$I$3$G$b%?%@$($C$A%^%K%e%"%k$d(B
$BC&$.$?$F$N%Q!{!{%#!(B5$BE@$r#5K|1_(B
(B
(Bhttp://www.zero-city.com/galoo/index.html$B!!(B 
(B
(B
(B-- 
(BTo UNSUBSCRIBE, email to [EMAIL PROTECTED]
(Bwith a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#170635: libc6 2.3.1-3 to 2.3.1-5 upgrade breaks

[Magnus Danielson]

From: Anthony DeRobertis [EMAIL PROTECTED]
Subject: Re: Bug#170635: libc6 2.3.1-3 to 2.3.1-5 upgrade breaks
Date: 02 Dec 2002 01:17:27 -0500

 On Sun, 2002-12-01 at 21:19, Magnus Danielson wrote:
 
  rm /lib/ld-2.3.1.so
  
  I got the Device or resource busy message as a reply. It's because the file
  is in use by many tools:
 
 That shouldn't happen. File in use != name in use. rm removes names,
 not files.

Exactly! I know... it's even traditional UNIX AFAIK.

 And you using something weird as your root file system? That is
 something besides ext[23] or reiserfs?

EXT3. No strange options or anything. I can't think of any specific things
other than over-generous selection of Debian/unstable packages.

Cheers,
Magnus


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#166967: libc6: upgrade of libc6 may have broken jabber 1.4.2 server

[GOTO Masanori]

Jamin W. Collins wrote:
 I've recently built jabber-1.4.2a sources against the Debian
 libc-2.3.1-5 package and have no problem with my Jabber server.  It
 would appear the problems the original reporter was having have either
 been corrected between libc-2.3.1-3 and libc-2.3.1-5 or the problem was
 caused by something else.

Thanks for your report. From this report, I think this bug was already
fixed. If you stil have this problem, please try to check the
suggestion which Matt Zimmerman (thanks for your analysis) wrote.
Could I close this bug? 

-- gotom





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: bugs triage?

[GOTO Masanori]

At Sat, 30 Nov 2002 09:35:45 -0800,
Randolph Chung wrote:
 There are still many critical, grave and serious bugs listed in BTS 
 against glibc. Should we try to fix some of them? :-)

Thanks for your clarification.

 Critical:
 * #162551: libc6-sparc64 conflicts with fakeroot
   Package: libc6-sparc64; Severity: critical; Reported by: Julian Stoev 
[EMAIL PROTECTED]; 64 days old.
 
 This is a woody bug. BenC's proposed fix is:
 ] The fix will be to make libc6-sparc64 conflict with gcc-3.0,
 ] gcc-3.0-sparc64 and older fakeroot.
 
 This also requires that a new version of fakeroot be uploaded for
 woody-proposed-updates

Under my test, dpkg/apt does not complain. Does this still need to work?
Or should we need something to work with this proposal?

 * #165358: libc6 2.3.1-1 breaks fetchmail/exim (and others?)
   Package: libc6; Severity: critical; Reported by: Rene Engelhard 
[EMAIL PROTECTED]; 43 days old.
 
 This one is about whether to provide things like __libc_waitpid and
 __libc_fork temporarily for transition purposes. We should decide one
 way or another and either add the aliases or close the bug :-)

Yes. I would like to add __libc_waitpid/__libc_fork...
However, I agree it should be downgrade or change the sevelity as you say :)

 * #165374: =?iso-8859-15?q?Breaks_when_upgrading_to_2=2E3=2E1?=
   Package: libc6-dbg; Severity: critical; Reported by: 
=?iso-8859-15?q?Per_Lundberg?= [EMAIL PROTECTED]; 43 days old.
 
 If /usr/lib/debug is in your /etc/ld.so.conf, then installing the new
 glibc fails. mdz writes:
 ] I would be quite surprised if this were the only thing to break in this
 ] situation [...]
 ] This bug does not, in my opinion, warrant Severity: critical, if it is a
 ] bug at all.
 
 I'd tend to agree -- this is not a typical setup.

Hmm. Downgrading to important is more appropriate for me...

 * #166967: libc6: upgrade of libc6 may have broken jabber 1.4.2 server
   Package: libc6; Severity: critical; Reported by: John M Flinchbaugh 
[EMAIL PROTECTED]; Tags: sid; 31 days old.
 
 Someone else had followed up to say that the problem is no longer seen
 with a newer jabber; suggest we close this.

Seconded. I wait some period to listen to complain.

 * #167794: Wrong Pre-Depends
   Package: libc6; Severity: critical; Reported by: Martin Schulze 
[EMAIL PROTECTED]; 25 days old.
 
 Looks like this might be a problem in the buildd setup? There's not
 enough information in the bug to say, and I'm not sure why this is
 assigned to glibc.

I've closed this bug.

 * #169790: libc6: installation failure on dist-upgrade
   Package: libc6; Severity: critical; Reported by: Forrest Cahoon 
[EMAIL PROTECTED]; 10 days old.
 
 postinst fails when some of the packages being checked are not installed
 (I think). This was reported against 2.3.1-4. Has this been fixed?

It should be.

 * #170635: libc6 2.3.1-3 to 2.3.1-5 upgrade breaks
 Package: libc6; Severity: critical; Reported by: Magnus Danielson [EMAIL PROTECTED].
 
 Appears to be unreproducible; more info needed. Also appears to be
 isolated, maybe we should downgrade this.

This problem is apparently non glibc issue. I've closed this bug.

 Grave functionality bugs - outstanding
 (A list of all such bugs used to be available).
 
 * #165699: php4: apache segfault w/ php4 and mysql,imap loaded together related 
to #165563
   Package: libc6; Severity: grave; Reported by: David Raufeisen 
[EMAIL PROTECTED]; Tags: sid; merged with #165718, #165719; 40 days old.
 * #165718: php4-imap: apache segmentation fault when starting php4-imap module
   Package: libc6; Severity: grave; Reported by: Debian User 
[EMAIL PROTECTED]; Tags: sid; merged with #165699, #165719; 40 days old.
 * #165719: php4 possibly causes apache to stop functioning
   Package: libc6; Severity: grave; Reported by: Michel Lobert 
[EMAIL PROTECTED]; Tags: sid; merged with #165699, #165718; 40 days old.
 * #166414: apache: Apache non-functional after upgrade
   Package: libc6; Severity: grave; Reported by: Tony Hoyle [EMAIL PROTECTED]; 
Tags: sid; 35 days old.
 
 All these appear to be somehow related. Not sure what's the deal here
 yet.

...And still I don't understand what is the problem...
Are these bugs alive?

 * #169789: libc6: postinst broken: uninstallable if you upgrade from a version 
older than 2.2.94-1
   Package: libc6; Severity: grave; Reported by: Marco Nenciarini 
[EMAIL PROTECTED]; Tags: patch, sid; 10 days old.
 
 This one has been fixed. I'm going to close this bug.

Thanks.

 * #169818: libc6: runlevel can return =?iso-8859-1?q?=ABunknown=BB?=, which 
breaks restarts
   Package: libc6; Severity: grave; Reported by: Tollef Fog Heen [EMAIL PROTECTED]; 
10 days old.
 
 Has this one been fixed yet? Seems like a trivial fix.

Yup.

 * #170385: libc6 should conflict with wine ( 0.0.20021007-1) and perhaps other 
packages
 Package: libc6; Severity: grave; Reported by: Adrian 

Bug#170635: libc6 2.3.1-3 to 2.3.1-5 upgrade breaks

[Rene Engelhard]

Hi,

Magnus Danielson wrote:
   I got the Device or resource busy message as a reply. It's because the file
   is in use by many tools:
  
  That shouldn't happen. File in use != name in use. rm removes names,
  not files.
[...]
 
  And you using something weird as your root file system? That is
  something besides ext[23] or reiserfs?
 
 EXT3. No strange options or anything. I can't think of any specific things
 other than over-generous selection of Debian/unstable packages.

I got the same message too on a previous upgrade (IIRC on 2.2.5-x).
/ was ext3. After resetting / to ext2 it worked. I did not know whz
then, and I do not know if that is a bug in glibc, dpkg or kernel.

Regards,

Rene

-- 
 .''`.  Rene Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: bugs triage?

[Jeff Bailey]

On Mon, 2002-12-02 at 05:19, GOTO Masanori wrote:

  This is related to __libc_fork(). The submitter wants glibc to conflict
  with older wine. Do we ever do package-specific conflicts for libc?
  Seems like that would be difficult to maintain. Seems like this really
  is a wine issue; can we close/reassign this?

I don't think we need to conflict with packages because of bugs in their
package.

 IMO, introducing __libc_fork patch resolve all these issue. 
 In addition, I strongly object to use such a package-specific conflict.
 
 From this bug, introducing __libc_fork patch takes us two benefit:
 (1) we can safely upgrade from woody to sarge (2) we don't need to
 care such conflict. If there is no objection, I commit the patch.

I think we need to make a commitment as to when we're removing the patch
if we do this.  As before, upstream is making no commitment to keeping
these hidden interfaces stable and they have already changed some
interfaces that are now hidden.

So my proposal is that this hack be removed the day after sarge is
frozen/released.

It also has me wondering if glibc22-m68k-compat.dpatch could be removed
then too.  We could do a quick check to make sure that anything using
lchown with the wrong version number was binNMU'd and drop more baggage.

Tks,
Jeff Bailey

-- 
When you get to the heart,
use a knife and fork.
 - From instructions on how to eat an artichoke.



signature.asc
Description: This is a digitally signed message part

Bug#171451: libc6: summary (http://www.summary.net/) segfault

[Yann B]

Package: libc6
Version: 2.3.1-5
Severity: critical
Justification: breaks unrelated software



-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux server 2.4.18-xfs #2 lun aoû 19 10:09:24 CEST 2002 i686
Locale: LANG=fr, LC_CTYPE=fr (ignored: LC_ALL set)

Versions of packages libc6 depends on:
ii  libdb1-compat 2.1.3-7The Berkeley database routines [gl

-- no debconf information

*** /opt/summary/strace.txt
execve(./summary, [./summary], [/* 23 vars */]) = 0
fcntl(0, F_GETFD)   = 0
fcntl(1, F_GETFD)   = 0
fcntl(2, F_GETFD)   = 0
personality(PER_LINUX)  = 0
geteuid()   = 0
getuid()= 0
getegid()   = 0
getgid()= 0
brk(0)  = 0x81161f4
brk(0x8116214)  = 0x8116214
brk(0x8117000)  = 0x8117000
getpid()= 8667
umask(07)   = 022
umask(027)  = 07
rt_sigaction(SIGQUIT, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGQUIT, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGTERM, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGUSR1, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGUSR1, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGUSR1, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGINT, {0x807c198, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGHUP, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGHUP, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGHUP, {0x807c198, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
gettimeofday({1038844100, 40473}, NULL) = 0
getpid()= 8667
open(/tmp/jsharejxljad, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 3
unlink(/tmp/jsharejxljad) = 0
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64

Processed: Re: Bug#171411: bits/c++config.h incorrect wrt to existence of long double math.h extensions

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

 reassign 171411 glibc
Bug#171411: bits/c++config.h incorrect wrt to existence of long double math.h 
extensions
Bug reassigned from package `libstdc++5-dev' to `glibc'.

 severity 171411 important
Bug#171411: bits/c++config.h incorrect wrt to existence of long double math.h 
extensions
Severity set to `important'.

 merge 171411 16
Bug#16: sparc: libm has long double versions of math fx, but no prototypes
Bug#171411: bits/c++config.h incorrect wrt to existence of long double math.h 
extensions
Merged 16 171411.

 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#170635: libc6 2.3.1-3 to 2.3.1-5 upgrade breaks

[Anthony DeRobertis]

On Monday, December 2, 2002, at 09:27 AM, Rene Engelhard wrote:


I got the same message too on a previous upgrade (IIRC on 2.2.5-x).
/ was ext3. After resetting / to ext2 it worked. I did not know whz
then, and I do not know if that is a bug in glibc, dpkg or kernel.


If unlink on the file fails, I'd definitely go for kernel. Especially 
since changing back to ext2 fixes it.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#171451: marked as done (libc6: summary (http://www.summary.net/) segfault)

[Debian Bug Tracking System]

Your message dated Mon, 2 Dec 2002 08:30:30 -0800
with message-id [EMAIL PROTECTED]
and subject line Bug#171451: libc6: summary (http://www.summary.net/) segfault
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 2 Dec 2002 15:57:29 +
From [EMAIL PROTECTED] Mon Dec 02 09:57:28 2002
Return-path: [EMAIL PROTECTED]
Received: from (www.iconotec.com) [213.56.84.225] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18Iswp-00012S-00; Mon, 02 Dec 2002 09:57:28 -0600
Received: by www.iconotec.com (Postfix, from userid 0)
id 2DAEF3C23A6E; Mon,  2 Dec 2002 16:57:22 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: Yann B [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: libc6: summary (http://www.summary.net/) segfault
X-Mailer: reportbug 2.9
Date: Mon, 02 Dec 2002 16:57:22 +0100
Message-Id: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=0.6 required=5.0
tests=SPAM_PHRASE_00_01
version=2.41
X-Spam-Level: 

Package: libc6
Version: 2.3.1-5
Severity: critical
Justification: breaks unrelated software



-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux server 2.4.18-xfs #2 lun aoû 19 10:09:24 CEST 2002 i686
Locale: LANG=fr, LC_CTYPE=fr (ignored: LC_ALL set)

Versions of packages libc6 depends on:
ii  libdb1-compat 2.1.3-7The Berkeley database routines [gl

-- no debconf information

*** /opt/summary/strace.txt
execve(./summary, [./summary], [/* 23 vars */]) = 0
fcntl(0, F_GETFD)   = 0
fcntl(1, F_GETFD)   = 0
fcntl(2, F_GETFD)   = 0
personality(PER_LINUX)  = 0
geteuid()   = 0
getuid()= 0
getegid()   = 0
getgid()= 0
brk(0)  = 0x81161f4
brk(0x8116214)  = 0x8116214
brk(0x8117000)  = 0x8117000
getpid()= 8667
umask(07)   = 022
umask(027)  = 07
rt_sigaction(SIGQUIT, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGQUIT, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGTERM, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGUSR1, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGUSR1, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGUSR1, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGINT, {0x807c198, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGHUP, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGHUP, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGHUP, {0x807c198, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
gettimeofday({1038844100, 40473}, NULL) = 0
getpid()= 8667
open(/tmp/jsharejxljad, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 3
unlink(/tmp/jsharejxljad) = 0
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64

Bug#171451: libc6: summary (http://www.summary.net/) segfault

[Jeff Bailey]

Good grief, what do you expect us to do with this?

Try again.  Explain *which* program is segfaulting, the steps to
reproduce, and a clear explanation as to why it's glibc's fault.

The fact that it happened after an upgrade doesn't tell me that the
program isn't relying on undefined behaviour.

Tks,
Jeff Bailey

On Mon, Dec 02, 2002 at 04:57:22PM +0100, Yann B wrote:
 Package: libc6
 Version: 2.3.1-5
 Severity: critical
 Justification: breaks unrelated software
 
 
 
 -- System Information:
 Debian Release: testing/unstable
 Architecture: i386
 Kernel: Linux server 2.4.18-xfs #2 lun ao{ 19 10:09:24 CEST 2002 i686
 Locale: LANG=fr, LC_CTYPE=fr (ignored: LC_ALL set)
 
 Versions of packages libc6 depends on:
 ii  libdb1-compat 2.1.3-7The Berkeley database routines [gl
 
 -- no debconf information
 
 *** /opt/summary/strace.txt
 execve(./summary, [./summary], [/* 23 vars */]) = 0
 fcntl(0, F_GETFD)   = 0
 fcntl(1, F_GETFD)   = 0
 fcntl(2, F_GETFD)   = 0
 personality(PER_LINUX)  = 0
 geteuid()   = 0
 getuid()= 0
 getegid()   = 0
 getgid()= 0
 brk(0)  = 0x81161f4
 brk(0x8116214)  = 0x8116214
 brk(0x8117000)  = 0x8117000
 getpid()= 8667
 umask(07)   = 022
 umask(027)  = 07
 rt_sigaction(SIGQUIT, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
 rt_sigaction(SIGQUIT, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
 rt_sigaction(SIGQUIT, {0x807c160, [], 0x400}, NULL, 8) = 0
 rt_sigaction(SIGTERM, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
 rt_sigaction(SIGTERM, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
 rt_sigaction(SIGTERM, {0x807c160, [], 0x400}, NULL, 8) = 0
 rt_sigaction(SIGUSR1, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
 rt_sigaction(SIGUSR1, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
 rt_sigaction(SIGUSR1, {0x807c160, [], 0x400}, NULL, 8) = 0
 rt_sigaction(SIGINT, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
 rt_sigaction(SIGINT, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
 rt_sigaction(SIGINT, {0x807c198, [], 0x400}, NULL, 8) = 0
 rt_sigaction(SIGHUP, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
 rt_sigaction(SIGHUP, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
 rt_sigaction(SIGHUP, {0x807c198, [], 0x400}, NULL, 8) = 0
 rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0
 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
 gettimeofday({1038844100, 40473}, NULL) = 0
 getpid()= 8667
 open(/tmp/jsharejxljad, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 3
 unlink(/tmp/jsharejxljad) = 0
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, 

[halls@debian.org: Bug#170044: openoffice.org: All OO programs crash with relocation error]

[Chris Halls]

Forwarding to debian-glibc because I am beginning to suspect a problem with the
lazy linker/loader code.

- Forwarded message from Chris Halls [EMAIL PROTECTED] -

Date: Fri, 29 Nov 2002 13:50:22 +0100
From: Chris Halls [EMAIL PROTECTED]
Subject: Bug#170044: openoffice.org: All OO programs crash with relocation error

On Thu, Nov 21, 2002 at 02:38:20PM +0100, Christian Perrier wrote:
 bubulle@mykerinos:~ ooffice 
 Gnome session manager detected - session management disabled
 /usr/lib/openoffice/program/soffice.bin: relocation error:
 /usr/lib/openoffice/program/libvcl641li.so: symbol _ZN3psp10PrinterGfxC1Ev,
 version LIBPSPRINT_1_0 not defined in file libpsp641li.so with link time
 reference

I have a very similar problem on my build:

chris@shawn:~/OpenOffice.org643$ ./soffice
/home/chris/OpenOffice.org643/program/soffice.bin: relocation error:
/home/chris/OpenOffice.org643/program/libsvx643li.so: symbol
_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit, version UDK_3_0_0 not
defined in file libcppuhelper3gcc3.so with link time reference

Turning on LD_DEBUG to see what the linker is doing:

chris@shawn:~/OpenOffice.org643$ (LD_DEBUG=all ./soffice 21) | grep 
_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit
27564:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/soffice.bin
27564:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libsvl643li.so
27564:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libvcl643li.so
27564:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libcppu.so.3
27564:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libcppuhelper3gcc3.so
27564:  /home/chris/OpenOffice.org643/program/libsvx643li.so: error: relocation error: 
symbol _ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit, version UDK_3_0_0 not 
defined in file libcppuhelper3gcc3.so with link time reference (fatal)
/home/chris/OpenOffice.org643/program/soffice.bin: relocation error: 
/home/chris/OpenOffice.org643/program/libsvx643li.so: symbol 
_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit, version UDK_3_0_0 not defined in 
file libcppuhelper3gcc3.so with link time reference

That symbol is not defined in libcppuhelper3gcc3.so - it is defined in
libsvx643li.so.  And if I set LD_BIND_NOW, it works...

chris@shawn:~/OpenOffice.org643$ (LD_DEBUG=all LD_BIND_NOW=1 ./soffice 21) | grep 
_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/soffice.bin
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libsvl643li.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libvcl643li.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libcppu.so.3
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libcppuhelper3gcc3.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libtl643li.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libvos2gcc3.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libsal.so.3
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libutl643li.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libucbhelper2gcc3.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libcomphelp2.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libsalhelper3gcc3.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libsvt643li.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/usr/X11R6/lib/libXext.so.6
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/usr/X11R6/lib/libSM.so.6
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/usr/X11R6/lib/libICE.so.6
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/usr/X11R6/lib/libX11.so.6
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 

Bug#171451: libc6: summary (http://www.summary.net/) segfault

[Yann Bizeul]

Package: libc6
Version: 2.3.1-5
Severity: critical
Justification: breaks unrelated software

# ./summary
Welcome to Summary/1.5.7.  Copyright (c) 1998-2001 by Jason T. Linhart.
This program is shareware. Please read the doc file.
Segmentation fault
# file summary
summary: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for 
GNU/Linux 2.0.0, statically linked, stripped

I think this is related to libc6 because summary segfaults when trying 
to read ELF headers of ld-linux.so.2. In fact this happened just after 
an upgrade containing libc6.
Can this be something else ? I'm open to every testing you wish

this version of summary works fine on a redhat 8 system

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux server 2.4.18-xfs #2 lun ao{ 19 10:09:24 CEST 2002 i686
Locale: LANG=fr, LC_CTYPE=fr (ignored: LC_ALL set)

Versions of packages libc6 depends on:
ii  libdb1-compat 2.1.3-7The Berkeley database 
routines [gl

-- no debconf information

*** /opt/summary/strace.txt
execve(./summary, [./summary], [/* 23 vars */]) = 0
fcntl(0, F_GETFD)   = 0
fcntl(1, F_GETFD)   = 0
fcntl(2, F_GETFD)   = 0
personality(PER_LINUX)  = 0
geteuid()   = 0
getuid()= 0
getegid()   = 0
getgid()= 0
brk(0)  = 0x81161f4
brk(0x8116214)  = 0x8116214
brk(0x8117000)  = 0x8117000
getpid()= 8667
umask(07)   = 022
umask(027)  = 07
rt_sigaction(SIGQUIT, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 
8) = 0
rt_sigaction(SIGQUIT, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 
0
rt_sigaction(SIGQUIT, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 
8) = 0
rt_sigaction(SIGTERM, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 
0
rt_sigaction(SIGTERM, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGUSR1, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 
8) = 0
rt_sigaction(SIGUSR1, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 
0
rt_sigaction(SIGUSR1, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 
8) = 0
rt_sigaction(SIGINT, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGINT, {0x807c198, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGHUP, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 
8) = 0
rt_sigaction(SIGHUP, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGHUP, {0x807c198, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
gettimeofday({1038844100, 40473}, NULL) = 0
getpid()= 8667
open(/tmp/jsharejxljad, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 3
unlink(/tmp/jsharejxljad) = 0
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64

Bug#171451: libc6: summary (http://www.summary.net/) segfault

[Daniel Jacobowitz]

debian-glibc folks, this sounds like the ctype crash that we thought we
had fixed.  The older dynamic linker is crashing loading
libnss_files.so.2...  I'll try to figure out where.

On Mon, Dec 02, 2002 at 05:44:13PM +0100, Yann Bizeul wrote:
 Package: libc6
 Version: 2.3.1-5
 Severity: critical
 Justification: breaks unrelated software
 
 # ./summary
 Welcome to Summary/1.5.7.  Copyright (c) 1998-2001 by Jason T. Linhart.
 This program is shareware. Please read the doc file.
 Segmentation fault
 # file summary
 summary: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for 
 GNU/Linux 2.0.0, statically linked, stripped
 
 I think this is related to libc6 because summary segfaults when trying 
 to read ELF headers of ld-linux.so.2. In fact this happened just after 
 an upgrade containing libc6.
 Can this be something else ? I'm open to every testing you wish
 
 this version of summary works fine on a redhat 8 system
 
 -- System Information:
 Debian Release: testing/unstable
 Architecture: i386
 Kernel: Linux server 2.4.18-xfs #2 lun ao{ 19 10:09:24 CEST 2002 i686
 Locale: LANG=fr, LC_CTYPE=fr (ignored: LC_ALL set)
 
 Versions of packages libc6 depends on:
 ii  libdb1-compat 2.1.3-7The Berkeley database 
 routines [gl
 
 -- no debconf information
 

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

RH glibc and __ctype_b

[Daniel Jacobowitz]

I'm looking at the changes Red Hat has for __ctype_b (i.e. exporting it and
also not crashing running static binaries).  There's something that doesn't
seem to work on Debian but does on Red Hat, and I think I know why.  We're
based on 2.3.1+cvs, so we include this patch:

+  /* We need the .symver declarations these macros generate so that
+ our references are explicitly bound to the versioned symbol names
+ rather than the unadorned names that are not exported.  When the
+ linker sees these bound to local symbols (as the unexported names are)
+ then it doesn't generate a proper relocation to the global symbols.
+ We need those relocations so that a versioned definition with a COPY
+ reloc in an executable will override the libc.so definition.  */
+
+//compat_symbol (libc, __ctype_b, __ctype_b, GLIBC_2_0);
+//compat_symbol (libc, __ctype_tolower, __ctype_tolower, GLIBC_2_0);
+//compat_symbol (libc, __ctype_toupper, __ctype_toupper, GLIBC_2_0);
+compat_symbol (libc, __ctype32_b, __ctype32_b, GLIBC_2_0);
+compat_symbol (libc, __ctype32_tolower, __ctype32_tolower, GLIBC_2_2);
+compat_symbol (libc, __ctype32_toupper, __ctype32_toupper, GLIBC_2_2);
+
 //  __ctype_b = current (uint16_t, CLASS, 128);
 //  __ctype_toupper = current (uint32_t, TOUPPER, 128);
 //  __ctype_tolower = current (uint32_t, TOLOWER, 128);

Adding the compat_symbol for __ctype32_b here causes glibc 2.2.5 static
binaries to crash.

I see in the .spec changelog that you fixed this problem a different way in
2.2.93-5, but since I can't locate a copy of 2.2.93-4 to compare against I
can't figure out how the fix works.  You've got
locale/lc-ctype.c:
extern const uint32_t *__ctype32_b;
   __ctype32_b = current (uint32_t, CLASS32, 0);
and ctype/ctype-info.c:
  const __uint32_t *__ctype32_b = b (__uint32_t, class32, 0);
  compat_symbol (libc, __ctype32_b, __ctype32_b, GLIBC_2_0);

So won't it bind to the wrong copy of __ctype32_b?


-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: RH glibc and __ctype_b

[Roland McGrath]

I'm not sure exactly what you are asking.

What makes old static binaries crash when they try to load a new libc.so is
an old bug in the dynamic loading code when handling a reference within an
object to a hidden symbol in the same object.  That was fixed by this change:

2002-09-18  Roland McGrath  [EMAIL PROTECTED]

* elf/do-rel.h (elf_dynamic_do_rel): Mask off 0x8000 bit (hidden flag)
from the value taken from the DT_VERSYM table.
* elf/dl-runtime.c (fixup, profile_fixup): Likewise.
* sysdeps/mips/dl-machine.h (__dl_runtime_resolve): Likewise.
(RESOLVE_GOTSYM): Likewise.

Obviously, existing static binaries will continue to have that bug.  It
makes them crash when they come across such a symbol.  In stock 2.3.1,
__ctype_b et al are such symbols because they are not exported at link time.
The compat_symbol uses are what prevent the link-time export (in nm output,
you can see [EMAIL PROTECTED] vs __ctype_b@@GLIBC_2.0 and the like;
in objdump --dynamic-syms output you can see GLIBC_2.0 vs (GLIBC_2.0)).

In the RHL version of glibc, those symbols are exported again by omitting
the compat_symbol uses.  The both avoids tickling the aforementioned bug,
and also lets existing .a's and .o's compiled with the old ctype.h be
usable.  If you want to do that, just comment out the compat_symbol's.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: RH glibc and __ctype_b

[Daniel Jacobowitz]

On Mon, Dec 02, 2002 at 12:21:50PM -0800, Roland McGrath wrote:
 I'm not sure exactly what you are asking.
 
 What makes old static binaries crash when they try to load a new libc.so is
 an old bug in the dynamic loading code when handling a reference within an
 object to a hidden symbol in the same object.  That was fixed by this change:
 
 2002-09-18  Roland McGrath  [EMAIL PROTECTED]
 
   * elf/do-rel.h (elf_dynamic_do_rel): Mask off 0x8000 bit (hidden flag)
   from the value taken from the DT_VERSYM table.
   * elf/dl-runtime.c (fixup, profile_fixup): Likewise.
   * sysdeps/mips/dl-machine.h (__dl_runtime_resolve): Likewise.
   (RESOLVE_GOTSYM): Likewise.
 
 Obviously, existing static binaries will continue to have that bug.  It
 makes them crash when they come across such a symbol.  In stock 2.3.1,
 __ctype_b et al are such symbols because they are not exported at link time.
 The compat_symbol uses are what prevent the link-time export (in nm output,
 you can see [EMAIL PROTECTED] vs __ctype_b@@GLIBC_2.0 and the like;
 in objdump --dynamic-syms output you can see GLIBC_2.0 vs (GLIBC_2.0)).
 
 In the RHL version of glibc, those symbols are exported again by omitting
 the compat_symbol uses.  The both avoids tickling the aforementioned bug,
 and also lets existing .a's and .o's compiled with the old ctype.h be
 usable.  If you want to do that, just comment out the compat_symbol's.

I suppose what really confuses me is that the compat_symbol entries for
__ctype_* are commented out in RHL glibc, but not for __ctype32_*. 
Why the asymmetry?

With the __ctype32_* ones present, I don't see how to both:
 - Avoid the crash in old static linkers
 - Handle application  R_*_COPY relocs correctly for __ctype32_*.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: RH glibc and __ctype_b

[Roland McGrath]

 I suppose what really confuses me is that the compat_symbol entries for
 __ctype_* are commented out in RHL glibc, but not for __ctype32_*. 
 Why the asymmetry?

In the current RHL glibc sources, both are treated the same.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Sucess/problems with libc6-i686

[David Schleef]

I've been playing with building and using the libc6-i686 package
recently, mainly to help track down a Red Hat bug.

A few little problems I noticed:

 - I think the .postinst is really supposed to be the .postrm

 - libc6-i686 contains /lib/ld-linux.so.2, which conflicts with
   libc6.  Simply removing this file from the packge make it work.
 
 - The default CFLAGS is -O99 -fomit-frame-pointer
   -D__USE_STRING_INLINES.  I'm not sure if this is upstream's
   idea of a joke or what, but it causes massive instability in
   pthreads.  -O2 works fine.  -O3 causes subtle problems that
   I've been seeing in Red Hat 8.0's package.  (Corruption in
   pthread's data structures.)

After fixing those, it seems to be rather stable.

I wish I could say that I see massive performance improvements, but
I don't.



dave...



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: RH glibc and __ctype_b

[Daniel Jacobowitz]

On Mon, Dec 02, 2002 at 12:32:33PM -0800, Roland McGrath wrote:
  I suppose what really confuses me is that the compat_symbol entries for
  __ctype_* are commented out in RHL glibc, but not for __ctype32_*. 
  Why the asymmetry?
 
 In the current RHL glibc sources, both are treated the same.

That'll teach me - I looked at RHL 8.0 instead of rawhide, and so did
GOTO.  Thanks.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

cvs commit to glibc-package/debian/patches by dan

[Debian GLibc CVS Master]

Repository: glibc-package/debian/patches
who:dan
time:   Mon Dec  2 15:34:31 MST 2002
Log Message:
  - Update glibc23-ctype-compat.patch to fix segfaults in old static
binaries (Closes: #171451).
  

Files:
changed:glibc23-ctype-compat.dpatch


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

cvs commit to glibc-package/debian by dan

[Debian GLibc CVS Master]

Repository: glibc-package/debian
who:dan
time:   Mon Dec  2 15:34:31 MST 2002
Log Message:
  - Update glibc23-ctype-compat.patch to fix segfaults in old static
binaries (Closes: #171451).
  

Files:
changed:changelog


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: RH glibc and __ctype_b

[Jakub Jelinek]

On Mon, Dec 02, 2002 at 03:29:17PM -0500, Daniel Jacobowitz wrote:
  In the RHL version of glibc, those symbols are exported again by omitting
  the compat_symbol uses.  The both avoids tickling the aforementioned bug,
  and also lets existing .a's and .o's compiled with the old ctype.h be
  usable.  If you want to do that, just comment out the compat_symbol's.
 
 I suppose what really confuses me is that the compat_symbol entries for
 __ctype_* are commented out in RHL glibc, but not for __ctype32_*. 
 Why the asymmetry?

__ctype_* was changed because we had lots of .a files in the distro when
the __ctype* changes happened and it was too late to recompile them all.
We had no __ctype32_* that I could find, hence I left what was
in glibc CVS for these. Old binaries/libraries should run fine (with
exception of statically linked progs) and newly compiled ones will use
__ctype*_loc instead.

Jakub


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: bugs triage?

[Carlos O'Donell]

  Package: glibc; Severity: serious; Reported by: Branden Robinson 
[EMAIL PROTECTED]; Tags: help.
  
  Carlos is looking at this one I think.
 
 Carlos?
 
 -- gotom
 

I'm working on it. I'm entering examination period in university and my
time is disappearing. I'm fixing a fesetround() that was just seen on
HP's test-drive systems (getting more testing is great!).

When are we aiming for a -5?

c.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: bugs triage?

[Daniel Jacobowitz]

On Mon, Dec 02, 2002 at 05:45:43PM -0500, Carlos O'Donell wrote:
   Package: glibc; Severity: serious; Reported by: Branden Robinson 
[EMAIL PROTECTED]; Tags: help.
   
   Carlos is looking at this one I think.
  
  Carlos?
  
  -- gotom
  
 
 I'm working on it. I'm entering examination period in university and my
 time is disappearing. I'm fixing a fesetround() that was just seen on
 HP's test-drive systems (getting more testing is great!).
 
 When are we aiming for a -5?

It'll be -6, and pretty soon.  Jeff's doing the CVS patch right now...

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#171502: locales: improve localization of locales.templates

[Denis Barbier]

Package: locales
Version: 2.3.1-5
Severity: minor
Tags: patch

Hi,

strings Leave alone and None are hardcoded and cannot be localized
in the templates file.  Here is a patch 

Denis

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux france0danemark2 2.4.18-386 #2 Sun Apr 14 10:38:08 EST 2002 i586
Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (ignored: LC_ALL set)

Versions of packages locales depends on:
ii  debconf   1.2.16 Debian configuration management sy
ii  libc6 [glibc-2.3.1-5] 2.3.1-5GNU C Library: Shared libraries an

-- debconf information excluded


Index: config
===
RCS file: /cvs/glibc/glibc-package/debian/locales/DEBIAN/config,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 config
--- config  25 Jul 2002 14:37:00 -  1.1.1.1
+++ config  2 Dec 2002 22:48:59 -
@@ -23,7 +23,11 @@
 
 db_get locales/locales_to_be_generated  DEFAULT_LOCALES=$(echo $RET | sed -e 's/ [^ 
]*,/,/g' -e 's/ [^ ]*$//')
 
-test -z $DEFAULT_LOCALES || DEFAULT_LOCALES=, $DEFAULT_LOCALES
-db_subst locales/default_environment_locale locales Leave alone, None, 
C$DEFAULT_LOCALES
+if test -z $DEFAULT_LOCALES; then
+DEFAULT_LOCALES=C
+else
+DEFAULT_LOCALES=C, $DEFAULT_LOCALES
+fi
+db_subst locales/default_environment_locale locales $DEFAULT_LOCALES
 db_input medium locales/default_environment_locale || true
 db_go
Index: templates
===
RCS file: /cvs/glibc/glibc-package/debian/locales/DEBIAN/templates,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 templates
--- templates   25 Jul 2002 14:37:00 -  1.1.1.1
+++ templates   2 Dec 2002 22:48:59 -
@@ -1,6 +1,6 @@
 Template: locales/locales_to_be_generated
 Type: multiselect
-Choices: ${locales}
+Choices: Leave alone, None, ${locales}
 Description: Select locales to be generated.
  You can choose locales to be generated by selecting locales you want.
  Selected locales will be saved to `/etc/locale.gen' file. You can also

Re: bugs triage?

[Randolph Chung]

 I'm working on it. I'm entering examination period in university and my
 time is disappearing. I'm fixing a fesetround() that was just seen on
 HP's test-drive systems (getting more testing is great!).

let me know if i can help :-)
randolph


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

cvs commit to glibc-package/debian by dan

[Debian GLibc CVS Master]

Repository: glibc-package/debian
who:dan
time:   Mon Dec  2 19:00:19 MST 2002
Log Message:
  - Allow building from the CVS checkout without getting CVS dirs in the
resulting packages.  Whew.
  

Files:
changed:changelog


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

[PATCH] fesetround() bug fixed in hppa

[Carlos O'Donell]

  I'm working on it. I'm entering examination period in university and my
  time is disappearing. I'm fixing a fesetround() that was just seen on
  HP's test-drive systems (getting more testing is great!).
 
 let me know if i can help :-)
 randolph

Fixed. Dpatch attached :)

c.


#! /bin/sh -e

# DP: Description: Corrects error in fesetround() when clearning FPU rounding mask. 
# DP: Author: Carlos O'Donell [EMAIL PROTECTED]
# DP: Upstream status: Submitted
# DP: Status: Details: Awaiting to hear from upstream.
# DP: Date: Monday December 2, 2002

if [ $# -ne 2 ]; then
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
fi
case $1 in
-patch) patch -d $2 -f --no-backup-if-mismatch -p1  $0;;
-unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p1  $0;;
*)
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
esac
exit 0

# append the patch here and adjust the -p? flag in the patch calls.
--- glibc-2.3.1/sysdeps/hppa/fpu/fesetround.c   2002-12-02 16:36:36.0 -0500
+++ glibc-2.3.1/sysdeps/hppa/fpu/fesetround.c   2002-12-02 16:36:59.0 -0500
@@ -31,7 +31,7 @@
 
   /* Get the current status word. */
   __asm__ (fstd %%fr0,0(%1) : =m (*sw) : r (sw));
-  sw[0] = ~FE_UPWARD;
+  sw[0] = ~FE_DOWNWARD;
   sw[0] |= round;
   __asm__ (fldd 0(%0),%%fr0 : : r (sw));
 

[PATCH] fix masking error in fesetround() on hppa

[Carlos O'Donell]

libc-alpha,

Thanks to HP's testdrive users, we found and fixed a small masking bug
in fesetround(). Should use ~FE_DOWNWARD since this is the rounding mask
set to all ones, and will clear the mask before or'ing the round value.

It was suggested that a test case could be made of this, where glibc
tries to set and get various combinations of FE_DOWNWARD, FE_UPWARD,
FE_TONEAREST, and FE_UPWARD. I could provide such a testcase if it was
deemed usefull. 

c.

---

2002-12-02  Carlos O'Donell  [EMAIL PROTECTED]

* sysdeps/hppa/fpu/fesetround.c: 
(fesetround): Use ~FE_DOWNWARD so both bits of RM are cleared.

--- glibc-2.3.1/sysdeps/hppa/fpu/fesetround.c   2002-12-02 16:36:36.0 -0500
+++ glibc-2.3.1/sysdeps/hppa/fpu/fesetround.c   2002-12-02 16:36:59.0 -0500
@@ -31,7 +31,7 @@
 
   /* Get the current status word. */
   __asm__ (fstd %%fr0,0(%1) : =m (*sw) : r (sw));
-  sw[0] = ~FE_UPWARD;
+  sw[0] = ~FE_DOWNWARD;
   sw[0] |= round;
   __asm__ (fldd 0(%0),%%fr0 : : r (sw));
 

Re: [PATCH] fix masking error in fesetround() on hppa

[Roland McGrath]

I've put that fix in.  I'm not quite sure what you are suggesting for a new
test, but test cases that fail on known bug regressions (i.e. one that
fails before your fix and works after it) are always welcome.


Thanks,
Roland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [PATCH] Make sure kernel is recent when installing on HPPA

[Carlos O'Donell]

 --- debian/libc/DEBIAN/preinst.orig   2002-12-02 20:21:46.0 -0500
 +++ debian/libc/DEBIAN/preinst2002-12-02 20:31:16.0 -0500
 @@ -100,6 +100,19 @@
   fi
   fi
  fi
 +# HPPA boxes require latest fixes in the kernel to function properly.
 +if [ $realarch = parisc64 ] || [ $realarch = parisc ]
 +then
 + kernel_ver=`uname -r`
 + if dpkg --compare-versions $kernel_ver lt 2.4.19
 + then
 + echo WARNING: This version of libc6 requires that you be running
 + echo atleast a 2.4.19 kernel in order to work properly. Earlier
 + echo kernels did not provide the proper functionality in order 
 + echo for the system to be stable. 
 + exit 1
 + fi
 +fi
  fi
  
  exit 0


Built and tested deb's on PA using this patch and it all works.
This should be included in the -6 release.

c.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [PATCH] fesetround() bug fixed in hppa

[Carlos O'Donell]

 #! /bin/sh -e
 
 # DP: Description: Corrects error in fesetround() when clearning FPU rounding mask. 
 # DP: Author: Carlos O'Donell [EMAIL PROTECTED]
 # DP: Upstream status: Submitted
 ^ 
 Accepted.

 # DP: Status: Details: Awaiting to hear from upstream.
 ^^^ 
 Applied upsream.  

 # DP: Date: Monday December 2, 2002


This may be the first time in history where I generate a dpatch and it
never gets used because upstream was in sync before we made the
cvs.dpatch :)

c.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Processed: retitle

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

 retitle 165881 [hppa] EAGAIN != EWOULDBLOCK, breaks various programs
Bug#165881: telnetd aborts when EAGAIN returned from writev
Changed Bug title.

 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#170635: libc6 2.3.1-3 to 2.3.1-5 upgrade breaks

[Anthony DeRobertis]

On Sun, 2002-12-01 at 21:19, Magnus Danielson wrote:

 rm /lib/ld-2.3.1.so
 
 I got the Device or resource busy message as a reply. It's because the file
 is in use by many tools:

That shouldn't happen. File in use != name in use. rm removes names,
not files.

And you using something weird as your root file system? That is
something besides ext[23] or reiserfs?


signature.asc
Description: This is a digitally signed message part

Bug#167794: marked as done (Wrong Pre-Depends)

[Debian Bug Tracking System]

Your message dated Mon, 02 Dec 2002 17:20:11 +0900
with message-id [EMAIL PROTECTED]
and subject line Processed: your mail
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 4 Nov 2002 22:37:42 +
From [EMAIL PROTECTED] Mon Nov 04 16:37:42 2002
Return-path: [EMAIL PROTECTED]
Received: from luonnotar.infodrom.org [195.124.48.78] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 188pqn-00010d-00; Mon, 04 Nov 2002 16:37:42 -0600
Received: by luonnotar.infodrom.org (Postfix, from userid 10)
id B7E14366B22; Mon,  4 Nov 2002 23:37:09 +0100 (CET)
Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.102 1998-Aug-2 #2)
from infodrom.org by finlandia.Infodrom.North.DE
via smail from stdin
id [EMAIL PROTECTED]
for [EMAIL PROTECTED]; Mon, 4 Nov 2002 23:28:54 +0100 (CET) 
Date: Mon, 4 Nov 2002 23:28:54 +0100
From: Martin Schulze [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Wrong Pre-Depends
Message-ID: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
User-Agent: Mutt/1.4i
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-6.6 required=5.0
tests=SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01,USER_AGENT,
  USER_AGENT_MUTT
version=2.41
X-Spam-Level: 

Package: coreutils
Version: 4.5.3-1
Severity: critical

I just tried to 'apt-get dist-upgrade' an m68k box and got bitten
by:

cut: /lib/libc.so.6: version `GLIBC_2.3' not found (required by cut)

It looks like coreutils are linked against a glibc 2.3 but only
Pre-Depends: libc6 (= 2.2.5-13) which is not strict enough.

Please upload a new coreutils package so it gets properly rebuilt
on all architectures and please correct the pre-dependency.

Regards,

Joey

-- 
Life is too short to run proprietary software.  -- Bdale Garbee

Please always Cc to me when replying to me on the lists.

---
Received: (at 167794-done) by bugs.debian.org; 2 Dec 2002 08:20:18 +
From [EMAIL PROTECTED] Mon Dec 02 02:20:18 2002
Return-path: [EMAIL PROTECTED]
Received: from oris.opensource.jp (oris.opensource.gr.jp) [218.44.239.73] 
(postfix)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18IloO-00020D-00; Mon, 02 Dec 2002 02:20:16 -0600
Received: from oris.opensource.jp (oris.opensource.jp [218.44.239.73])
by oris.opensource.gr.jp (Postfix) with ESMTP id 460DAC33C6
for [EMAIL PROTECTED]; Mon,  2 Dec 2002 17:20:11 +0900 (JST)
Date: Mon, 02 Dec 2002 17:20:11 +0900
Message-ID: [EMAIL PROTECTED]
From: GOTO Masanori [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Processed: your mail
In-Reply-To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
 FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - Ushinoya)
Content-Type: text/plain; charset=US-ASCII
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-5.8 required=5.0
tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT
version=2.41
X-Spam-Level: 

Current libc6 (2.3.1-5) and coreutils (4.5.3-3) on m68k works fine.

-- gotom

Bug#162551: libc6-sparc64 conflicts with fakeroot

[GOTO Masanori]

Was this bug fixed with libc6-sparc64 (2.2.5-11.2) and fakeroot (0.4.4-9.2)?
Refering from Bug#151448, it seems this bug is still alive, but
under my environment (woody) apt-get install does not complain.
Could I close this bug?

-- gotom

$B=O=w$+$*$j$N!H$*$9$9$a!I(B$B$h$s!*!*(B

[$B$+$*$j(B]

$B=O=w!!$+$*$j!!$N!!!H$*$9$9$a!I!!$h$s!*!*(B  
$B$"[EMAIL PROTECTED]>R2p$7$^$9(B
$BB>[EMAIL PROTECTED]($C$A%^%K%e%"%k$d(B
$BC&$.$?$F$N%Q!{!{%#!([EMAIL PROTECTED]|1_(B
(B
(Bhttp://www.zero-city.com/galoo/index.html$B!!(B 

Bug#166967: libc6: upgrade of libc6 may have broken jabber 1.4.2 server

[GOTO Masanori]

Jamin W. Collins wrote:
 I've recently built jabber-1.4.2a sources against the Debian
 libc-2.3.1-5 package and have no problem with my Jabber server.  It
 would appear the problems the original reporter was having have either
 been corrected between libc-2.3.1-3 and libc-2.3.1-5 or the problem was
 caused by something else.

Thanks for your report. From this report, I think this bug was already
fixed. If you stil have this problem, please try to check the
suggestion which Matt Zimmerman (thanks for your analysis) wrote.
Could I close this bug? 

-- gotom

Re: bugs triage?

[GOTO Masanori]

At Mon, 2 Dec 2002 14:43:27 +1000,
Anthony Towns wrote:
 On Sat, Nov 30, 2002 at 02:16:46PM -0800, Randolph Chung wrote:
* #167794: Wrong Pre-Depends
  Package: libc6; Severity: critical; Reported by: Martin Schulze 
[EMAIL PROTECTED]; 25 days old.
Looks like this might be a problem in the buildd setup? There's not
enough information in the bug to say, and I'm not sure why this is
assigned to glibc.
   No, it's not buildd setup; it's the result of a glibc bug (#165456).
  that bug is closed... so is this not a problem anymore?
 
 It remains a problem until all the miscompiled packages get reuploaded.
 A version of sendmail broken in this manner made it into testing, causing
 further problems. (This can be fixed by a source upload targetting at
 testing and going into testing-proposed-updates, for reference)

Umm, but from glibc point of view, it was already fixed.
So I've closed this bug. (To reopen this bug is ok if you want).
Sending bug reports to such broken packages is more practical, don't you?

-- gotom

Re: bugs triage?

[GOTO Masanori]

At Sat, 30 Nov 2002 09:35:45 -0800,
Randolph Chung wrote:
 There are still many critical, grave and serious bugs listed in BTS 
 against glibc. Should we try to fix some of them? :-)

Thanks for your clarification.

 Critical:
 * #162551: libc6-sparc64 conflicts with fakeroot
   Package: libc6-sparc64; Severity: critical; Reported by: Julian Stoev 
 [EMAIL PROTECTED]; 64 days old.
 
 This is a woody bug. BenC's proposed fix is:
 ] The fix will be to make libc6-sparc64 conflict with gcc-3.0,
 ] gcc-3.0-sparc64 and older fakeroot.
 
 This also requires that a new version of fakeroot be uploaded for
 woody-proposed-updates

Under my test, dpkg/apt does not complain. Does this still need to work?
Or should we need something to work with this proposal?

 * #165358: libc6 2.3.1-1 breaks fetchmail/exim (and others?)
   Package: libc6; Severity: critical; Reported by: Rene Engelhard [EMAIL 
 PROTECTED]; 43 days old.
 
 This one is about whether to provide things like __libc_waitpid and
 __libc_fork temporarily for transition purposes. We should decide one
 way or another and either add the aliases or close the bug :-)

Yes. I would like to add __libc_waitpid/__libc_fork...
However, I agree it should be downgrade or change the sevelity as you say :)

 * #165374: =?iso-8859-15?q?Breaks_when_upgrading_to_2=2E3=2E1?=
   Package: libc6-dbg; Severity: critical; Reported by: 
 =?iso-8859-15?q?Per_Lundberg?= [EMAIL PROTECTED]; 43 days old.
 
 If /usr/lib/debug is in your /etc/ld.so.conf, then installing the new
 glibc fails. mdz writes:
 ] I would be quite surprised if this were the only thing to break in this
 ] situation [...]
 ] This bug does not, in my opinion, warrant Severity: critical, if it is a
 ] bug at all.
 
 I'd tend to agree -- this is not a typical setup.

Hmm. Downgrading to important is more appropriate for me...

 * #166967: libc6: upgrade of libc6 may have broken jabber 1.4.2 server
   Package: libc6; Severity: critical; Reported by: John M Flinchbaugh 
 [EMAIL PROTECTED]; Tags: sid; 31 days old.
 
 Someone else had followed up to say that the problem is no longer seen
 with a newer jabber; suggest we close this.

Seconded. I wait some period to listen to complain.

 * #167794: Wrong Pre-Depends
   Package: libc6; Severity: critical; Reported by: Martin Schulze [EMAIL 
 PROTECTED]; 25 days old.
 
 Looks like this might be a problem in the buildd setup? There's not
 enough information in the bug to say, and I'm not sure why this is
 assigned to glibc.

I've closed this bug.

 * #169790: libc6: installation failure on dist-upgrade
   Package: libc6; Severity: critical; Reported by: Forrest Cahoon [EMAIL 
 PROTECTED]; 10 days old.
 
 postinst fails when some of the packages being checked are not installed
 (I think). This was reported against 2.3.1-4. Has this been fixed?

It should be.

 * #170635: libc6 2.3.1-3 to 2.3.1-5 upgrade breaks
 Package: libc6; Severity: critical; Reported by: Magnus Danielson [EMAIL 
 PROTECTED].
 
 Appears to be unreproducible; more info needed. Also appears to be
 isolated, maybe we should downgrade this.

This problem is apparently non glibc issue. I've closed this bug.

 Grave functionality bugs - outstanding
 (A list of all such bugs used to be available).
 
 * #165699: php4: apache segfault w/ php4 and mysql,imap loaded together 
 related to #165563
   Package: libc6; Severity: grave; Reported by: David Raufeisen [EMAIL 
 PROTECTED]; Tags: sid; merged with #165718, #165719; 40 days old.
 * #165718: php4-imap: apache segmentation fault when starting php4-imap 
 module
   Package: libc6; Severity: grave; Reported by: Debian User [EMAIL 
 PROTECTED]; Tags: sid; merged with #165699, #165719; 40 days old.
 * #165719: php4 possibly causes apache to stop functioning
   Package: libc6; Severity: grave; Reported by: Michel Lobert [EMAIL 
 PROTECTED]; Tags: sid; merged with #165699, #165718; 40 days old.
 * #166414: apache: Apache non-functional after upgrade
   Package: libc6; Severity: grave; Reported by: Tony Hoyle [EMAIL 
 PROTECTED]; Tags: sid; 35 days old.
 
 All these appear to be somehow related. Not sure what's the deal here
 yet.

...And still I don't understand what is the problem...
Are these bugs alive?

 * #169789: libc6: postinst broken: uninstallable if you upgrade from a 
 version older than 2.2.94-1
   Package: libc6; Severity: grave; Reported by: Marco Nenciarini [EMAIL 
 PROTECTED]; Tags: patch, sid; 10 days old.
 
 This one has been fixed. I'm going to close this bug.

Thanks.

 * #169818: libc6: runlevel can return =?iso-8859-1?q?=ABunknown=BB?=, 
 which breaks restarts
   Package: libc6; Severity: grave; Reported by: Tollef Fog Heen [EMAIL 
 PROTECTED]; 10 days old.
 
 Has this one been fixed yet? Seems like a trivial fix.

Yup.

 * #170385: libc6 should conflict with wine ( 0.0.20021007-1) and 
 perhaps other packages
 Package: libc6; Severity: grave; 

Re: bugs triage?

[Daniel Jacobowitz]

On Mon, Dec 02, 2002 at 07:19:10PM +0900, GOTO Masanori wrote:
 IMO, introducing __libc_fork patch resolve all these issue. 
 In addition, I strongly object to use such a package-specific conflict.
 
 From this bug, introducing __libc_fork patch takes us two benefit:
 (1) we can safely upgrade from woody to sarge (2) we don't need to
 care such conflict. If there is no objection, I commit the patch.

I agree; please do...

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Bug#170635: libc6 2.3.1-3 to 2.3.1-5 upgrade breaks

[Rene Engelhard]

Hi,

Magnus Danielson wrote:
   I got the Device or resource busy message as a reply. It's because the 
   file
   is in use by many tools:
  
  That shouldn't happen. File in use != name in use. rm removes names,
  not files.
[...]
 
  And you using something weird as your root file system? That is
  something besides ext[23] or reiserfs?
 
 EXT3. No strange options or anything. I can't think of any specific things
 other than over-generous selection of Debian/unstable packages.

I got the same message too on a previous upgrade (IIRC on 2.2.5-x).
/ was ext3. After resetting / to ext2 it worked. I did not know whz
then, and I do not know if that is a bug in glibc, dpkg or kernel.

Regards,

Rene

-- 
 .''`.  Rene Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73

Bug#171451: libc6: summary (http://www.summary.net/) segfault

[Yann B]

Package: libc6
Version: 2.3.1-5
Severity: critical
Justification: breaks unrelated software



-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux server 2.4.18-xfs #2 lun aoû 19 10:09:24 CEST 2002 i686
Locale: LANG=fr, LC_CTYPE=fr (ignored: LC_ALL set)

Versions of packages libc6 depends on:
ii  libdb1-compat 2.1.3-7The Berkeley database routines [gl

-- no debconf information

*** /opt/summary/strace.txt
execve(./summary, [./summary], [/* 23 vars */]) = 0
fcntl(0, F_GETFD)   = 0
fcntl(1, F_GETFD)   = 0
fcntl(2, F_GETFD)   = 0
personality(PER_LINUX)  = 0
geteuid()   = 0
getuid()= 0
getegid()   = 0
getgid()= 0
brk(0)  = 0x81161f4
brk(0x8116214)  = 0x8116214
brk(0x8117000)  = 0x8117000
getpid()= 8667
umask(07)   = 022
umask(027)  = 07
rt_sigaction(SIGQUIT, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGQUIT, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGTERM, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGUSR1, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGUSR1, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGUSR1, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGINT, {0x807c198, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGHUP, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGHUP, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGHUP, {0x807c198, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
gettimeofday({1038844100, 40473}, NULL) = 0
getpid()= 8667
open(/tmp/jsharejxljad, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 3
unlink(/tmp/jsharejxljad) = 0
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64

Processed: Re: Bug#171411: bits/c++config.h incorrect wrt to existence of long double math.h extensions

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

 reassign 171411 glibc
Bug#171411: bits/c++config.h incorrect wrt to existence of long double math.h 
extensions
Bug reassigned from package `libstdc++5-dev' to `glibc'.

 severity 171411 important
Bug#171411: bits/c++config.h incorrect wrt to existence of long double math.h 
extensions
Severity set to `important'.

 merge 171411 16
Bug#16: sparc: libm has long double versions of math fx, but no prototypes
Bug#171411: bits/c++config.h incorrect wrt to existence of long double math.h 
extensions
Merged 16 171411.

 thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Bug#170635: libc6 2.3.1-3 to 2.3.1-5 upgrade breaks

[Anthony DeRobertis]

On Monday, December 2, 2002, at 09:27 AM, Rene Engelhard wrote:
I got the same message too on a previous upgrade (IIRC on 2.2.5-x).
/ was ext3. After resetting / to ext2 it worked. I did not know whz
then, and I do not know if that is a bug in glibc, dpkg or kernel.
If unlink on the file fails, I'd definitely go for kernel. Especially 
since changing back to ext2 fixes it.

Bug#171451: marked as done (libc6: summary (http://www.summary.net/) segfault)

[Debian Bug Tracking System]

Your message dated Mon, 2 Dec 2002 08:30:30 -0800
with message-id [EMAIL PROTECTED]
and subject line Bug#171451: libc6: summary (http://www.summary.net/) segfault
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 2 Dec 2002 15:57:29 +
From [EMAIL PROTECTED] Mon Dec 02 09:57:28 2002
Return-path: [EMAIL PROTECTED]
Received: from (www.iconotec.com) [213.56.84.225] 
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18Iswp-00012S-00; Mon, 02 Dec 2002 09:57:28 -0600
Received: by www.iconotec.com (Postfix, from userid 0)
id 2DAEF3C23A6E; Mon,  2 Dec 2002 16:57:22 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: Yann B [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: libc6: summary (http://www.summary.net/) segfault
X-Mailer: reportbug 2.9
Date: Mon, 02 Dec 2002 16:57:22 +0100
Message-Id: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=0.6 required=5.0
tests=SPAM_PHRASE_00_01
version=2.41
X-Spam-Level: 

Package: libc6
Version: 2.3.1-5
Severity: critical
Justification: breaks unrelated software



-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux server 2.4.18-xfs #2 lun aoû 19 10:09:24 CEST 2002 i686
Locale: LANG=fr, LC_CTYPE=fr (ignored: LC_ALL set)

Versions of packages libc6 depends on:
ii  libdb1-compat 2.1.3-7The Berkeley database routines [gl

-- no debconf information

*** /opt/summary/strace.txt
execve(./summary, [./summary], [/* 23 vars */]) = 0
fcntl(0, F_GETFD)   = 0
fcntl(1, F_GETFD)   = 0
fcntl(2, F_GETFD)   = 0
personality(PER_LINUX)  = 0
geteuid()   = 0
getuid()= 0
getegid()   = 0
getgid()= 0
brk(0)  = 0x81161f4
brk(0x8116214)  = 0x8116214
brk(0x8117000)  = 0x8117000
getpid()= 8667
umask(07)   = 022
umask(027)  = 07
rt_sigaction(SIGQUIT, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGQUIT, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGTERM, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGUSR1, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGUSR1, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGUSR1, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGINT, {0x807c198, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGHUP, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGHUP, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGHUP, {0x807c198, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
gettimeofday({1038844100, 40473}, NULL) = 0
getpid()= 8667
open(/tmp/jsharejxljad, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 3
unlink(/tmp/jsharejxljad) = 0
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64

Bug#171451: libc6: summary (http://www.summary.net/) segfault

[Jeff Bailey]

Good grief, what do you expect us to do with this?

Try again.  Explain *which* program is segfaulting, the steps to
reproduce, and a clear explanation as to why it's glibc's fault.

The fact that it happened after an upgrade doesn't tell me that the
program isn't relying on undefined behaviour.

Tks,
Jeff Bailey

On Mon, Dec 02, 2002 at 04:57:22PM +0100, Yann B wrote:
 Package: libc6
 Version: 2.3.1-5
 Severity: critical
 Justification: breaks unrelated software
 
 
 
 -- System Information:
 Debian Release: testing/unstable
 Architecture: i386
 Kernel: Linux server 2.4.18-xfs #2 lun ao{ 19 10:09:24 CEST 2002 i686
 Locale: LANG=fr, LC_CTYPE=fr (ignored: LC_ALL set)
 
 Versions of packages libc6 depends on:
 ii  libdb1-compat 2.1.3-7The Berkeley database routines 
 [gl
 
 -- no debconf information
 
 *** /opt/summary/strace.txt
 execve(./summary, [./summary], [/* 23 vars */]) = 0
 fcntl(0, F_GETFD)   = 0
 fcntl(1, F_GETFD)   = 0
 fcntl(2, F_GETFD)   = 0
 personality(PER_LINUX)  = 0
 geteuid()   = 0
 getuid()= 0
 getegid()   = 0
 getgid()= 0
 brk(0)  = 0x81161f4
 brk(0x8116214)  = 0x8116214
 brk(0x8117000)  = 0x8117000
 getpid()= 8667
 umask(07)   = 022
 umask(027)  = 07
 rt_sigaction(SIGQUIT, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
 rt_sigaction(SIGQUIT, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
 rt_sigaction(SIGQUIT, {0x807c160, [], 0x400}, NULL, 8) = 0
 rt_sigaction(SIGTERM, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
 rt_sigaction(SIGTERM, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
 rt_sigaction(SIGTERM, {0x807c160, [], 0x400}, NULL, 8) = 0
 rt_sigaction(SIGUSR1, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
 rt_sigaction(SIGUSR1, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 0
 rt_sigaction(SIGUSR1, {0x807c160, [], 0x400}, NULL, 8) = 0
 rt_sigaction(SIGINT, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
 rt_sigaction(SIGINT, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
 rt_sigaction(SIGINT, {0x807c198, [], 0x400}, NULL, 8) = 0
 rt_sigaction(SIGHUP, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
 rt_sigaction(SIGHUP, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
 rt_sigaction(SIGHUP, {0x807c198, [], 0x400}, NULL, 8) = 0
 rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0
 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
 gettimeofday({1038844100, 40473}, NULL) = 0
 getpid()= 8667
 open(/tmp/jsharejxljad, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 3
 unlink(/tmp/jsharejxljad) = 0
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
 

[halls@debian.org: Bug#170044: openoffice.org: All OO programs crash with relocation error]

[Chris Halls]

Forwarding to debian-glibc because I am beginning to suspect a problem with the
lazy linker/loader code.

- Forwarded message from Chris Halls [EMAIL PROTECTED] -

Date: Fri, 29 Nov 2002 13:50:22 +0100
From: Chris Halls [EMAIL PROTECTED]
Subject: Bug#170044: openoffice.org: All OO programs crash with relocation 
error

On Thu, Nov 21, 2002 at 02:38:20PM +0100, Christian Perrier wrote:
 [EMAIL PROTECTED]:~ ooffice 
 Gnome session manager detected - session management disabled
 /usr/lib/openoffice/program/soffice.bin: relocation error:
 /usr/lib/openoffice/program/libvcl641li.so: symbol _ZN3psp10PrinterGfxC1Ev,
 version LIBPSPRINT_1_0 not defined in file libpsp641li.so with link time
 reference

I have a very similar problem on my build:

[EMAIL PROTECTED]:~/OpenOffice.org643$ ./soffice
/home/chris/OpenOffice.org643/program/soffice.bin: relocation error:
/home/chris/OpenOffice.org643/program/libsvx643li.so: symbol
_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit, version UDK_3_0_0 not
defined in file libcppuhelper3gcc3.so with link time reference

Turning on LD_DEBUG to see what the linker is doing:

[EMAIL PROTECTED]:~/OpenOffice.org643$ (LD_DEBUG=all ./soffice 21) | grep 
_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit
27564:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/soffice.bin
27564:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libsvl643li.so
27564:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libvcl643li.so
27564:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libcppu.so.3
27564:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libcppuhelper3gcc3.so
27564:  /home/chris/OpenOffice.org643/program/libsvx643li.so: error: relocation 
error: symbol _ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit, version 
UDK_3_0_0 not defined in file libcppuhelper3gcc3.so with link time reference 
(fatal)
/home/chris/OpenOffice.org643/program/soffice.bin: relocation error: 
/home/chris/OpenOffice.org643/program/libsvx643li.so: symbol 
_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit, version UDK_3_0_0 not 
defined in file libcppuhelper3gcc3.so with link time reference

That symbol is not defined in libcppuhelper3gcc3.so - it is defined in
libsvx643li.so.  And if I set LD_BIND_NOW, it works...

[EMAIL PROTECTED]:~/OpenOffice.org643$ (LD_DEBUG=all LD_BIND_NOW=1 ./soffice 
21) | grep _ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/soffice.bin
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libsvl643li.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libvcl643li.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libcppu.so.3
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libcppuhelper3gcc3.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libtl643li.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libvos2gcc3.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libsal.so.3
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libutl643li.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libucbhelper2gcc3.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libcomphelp2.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libsalhelper3gcc3.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/home/chris/OpenOffice.org643/program/libsvt643li.so
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/usr/X11R6/lib/libXext.so.6
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/usr/X11R6/lib/libSM.so.6
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/usr/X11R6/lib/libICE.so.6
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  lookup in 
file=/usr/X11R6/lib/libX11.so.6
27798:  symbol=_ZN12SvxPaperInfo12GetPaperSizeE8SvxPaper7MapUnit;  

Bug#171451: libc6: summary (http://www.summary.net/) segfault

[Yann Bizeul]

Package: libc6
Version: 2.3.1-5
Severity: critical
Justification: breaks unrelated software
# ./summary
Welcome to Summary/1.5.7.  Copyright (c) 1998-2001 by Jason T. Linhart.
This program is shareware. Please read the doc file.
Segmentation fault
# file summary
summary: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for 
GNU/Linux 2.0.0, statically linked, stripped

I think this is related to libc6 because summary segfaults when trying 
to read ELF headers of ld-linux.so.2. In fact this happened just after 
an upgrade containing libc6.
Can this be something else ? I'm open to every testing you wish

this version of summary works fine on a redhat 8 system
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux server 2.4.18-xfs #2 lun ao{ 19 10:09:24 CEST 2002 i686
Locale: LANG=fr, LC_CTYPE=fr (ignored: LC_ALL set)
Versions of packages libc6 depends on:
ii  libdb1-compat 2.1.3-7The Berkeley database 
routines [gl

-- no debconf information
*** /opt/summary/strace.txt
execve(./summary, [./summary], [/* 23 vars */]) = 0
fcntl(0, F_GETFD)   = 0
fcntl(1, F_GETFD)   = 0
fcntl(2, F_GETFD)   = 0
personality(PER_LINUX)  = 0
geteuid()   = 0
getuid()= 0
getegid()   = 0
getgid()= 0
brk(0)  = 0x81161f4
brk(0x8116214)  = 0x8116214
brk(0x8117000)  = 0x8117000
getpid()= 8667
umask(07)   = 022
umask(027)  = 07
rt_sigaction(SIGQUIT, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 
8) = 0
rt_sigaction(SIGQUIT, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 
0
rt_sigaction(SIGQUIT, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 
8) = 0
rt_sigaction(SIGTERM, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 
0
rt_sigaction(SIGTERM, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGUSR1, {0x807c160, [], SA_RESTART|0x400}, {SIG_DFL}, 
8) = 0
rt_sigaction(SIGUSR1, NULL, {0x807c160, [], SA_RESTART|0x400}, 8) = 
0
rt_sigaction(SIGUSR1, {0x807c160, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 
8) = 0
rt_sigaction(SIGINT, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGINT, {0x807c198, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGHUP, {0x807c198, [], SA_RESTART|0x400}, {SIG_DFL}, 
8) = 0
rt_sigaction(SIGHUP, NULL, {0x807c198, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGHUP, {0x807c198, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
gettimeofday({1038844100, 40473}, NULL) = 0
getpid()= 8667
open(/tmp/jsharejxljad, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 3
unlink(/tmp/jsharejxljad) = 0
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64
write(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 
64) = 64

Bug#171451: libc6: summary (http://www.summary.net/) segfault

[Daniel Jacobowitz]

debian-glibc folks, this sounds like the ctype crash that we thought we
had fixed.  The older dynamic linker is crashing loading
libnss_files.so.2...  I'll try to figure out where.

On Mon, Dec 02, 2002 at 05:44:13PM +0100, Yann Bizeul wrote:
 Package: libc6
 Version: 2.3.1-5
 Severity: critical
 Justification: breaks unrelated software
 
 # ./summary
 Welcome to Summary/1.5.7.  Copyright (c) 1998-2001 by Jason T. Linhart.
 This program is shareware. Please read the doc file.
 Segmentation fault
 # file summary
 summary: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for 
 GNU/Linux 2.0.0, statically linked, stripped
 
 I think this is related to libc6 because summary segfaults when trying 
 to read ELF headers of ld-linux.so.2. In fact this happened just after 
 an upgrade containing libc6.
 Can this be something else ? I'm open to every testing you wish
 
 this version of summary works fine on a redhat 8 system
 
 -- System Information:
 Debian Release: testing/unstable
 Architecture: i386
 Kernel: Linux server 2.4.18-xfs #2 lun ao{ 19 10:09:24 CEST 2002 i686
 Locale: LANG=fr, LC_CTYPE=fr (ignored: LC_ALL set)
 
 Versions of packages libc6 depends on:
 ii  libdb1-compat 2.1.3-7The Berkeley database 
 routines [gl
 
 -- no debconf information
 

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

RH glibc and __ctype_b

[Daniel Jacobowitz]

I'm looking at the changes Red Hat has for __ctype_b (i.e. exporting it and
also not crashing running static binaries).  There's something that doesn't
seem to work on Debian but does on Red Hat, and I think I know why.  We're
based on 2.3.1+cvs, so we include this patch:

+  /* We need the .symver declarations these macros generate so that
+ our references are explicitly bound to the versioned symbol names
+ rather than the unadorned names that are not exported.  When the
+ linker sees these bound to local symbols (as the unexported names are)
+ then it doesn't generate a proper relocation to the global symbols.
+ We need those relocations so that a versioned definition with a COPY
+ reloc in an executable will override the libc.so definition.  */
+
+//compat_symbol (libc, __ctype_b, __ctype_b, GLIBC_2_0);
+//compat_symbol (libc, __ctype_tolower, __ctype_tolower, GLIBC_2_0);
+//compat_symbol (libc, __ctype_toupper, __ctype_toupper, GLIBC_2_0);
+compat_symbol (libc, __ctype32_b, __ctype32_b, GLIBC_2_0);
+compat_symbol (libc, __ctype32_tolower, __ctype32_tolower, GLIBC_2_2);
+compat_symbol (libc, __ctype32_toupper, __ctype32_toupper, GLIBC_2_2);
+
 //  __ctype_b = current (uint16_t, CLASS, 128);
 //  __ctype_toupper = current (uint32_t, TOUPPER, 128);
 //  __ctype_tolower = current (uint32_t, TOLOWER, 128);

Adding the compat_symbol for __ctype32_b here causes glibc 2.2.5 static
binaries to crash.

I see in the .spec changelog that you fixed this problem a different way in
2.2.93-5, but since I can't locate a copy of 2.2.93-4 to compare against I
can't figure out how the fix works.  You've got
locale/lc-ctype.c:
extern const uint32_t *__ctype32_b;
   __ctype32_b = current (uint32_t, CLASS32, 0);
and ctype/ctype-info.c:
  const __uint32_t *__ctype32_b = b (__uint32_t, class32, 0);
  compat_symbol (libc, __ctype32_b, __ctype32_b, GLIBC_2_0);

So won't it bind to the wrong copy of __ctype32_b?


-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Re: RH glibc and __ctype_b

[Roland McGrath]

I'm not sure exactly what you are asking.

What makes old static binaries crash when they try to load a new libc.so is
an old bug in the dynamic loading code when handling a reference within an
object to a hidden symbol in the same object.  That was fixed by this change:

2002-09-18  Roland McGrath  [EMAIL PROTECTED]

* elf/do-rel.h (elf_dynamic_do_rel): Mask off 0x8000 bit (hidden flag)
from the value taken from the DT_VERSYM table.
* elf/dl-runtime.c (fixup, profile_fixup): Likewise.
* sysdeps/mips/dl-machine.h (__dl_runtime_resolve): Likewise.
(RESOLVE_GOTSYM): Likewise.

Obviously, existing static binaries will continue to have that bug.  It
makes them crash when they come across such a symbol.  In stock 2.3.1,
__ctype_b et al are such symbols because they are not exported at link time.
The compat_symbol uses are what prevent the link-time export (in nm output,
you can see [EMAIL PROTECTED] vs __ctype_b@@GLIBC_2.0 and the like;
in objdump --dynamic-syms output you can see GLIBC_2.0 vs (GLIBC_2.0)).

In the RHL version of glibc, those symbols are exported again by omitting
the compat_symbol uses.  The both avoids tickling the aforementioned bug,
and also lets existing .a's and .o's compiled with the old ctype.h be
usable.  If you want to do that, just comment out the compat_symbol's.

Re: RH glibc and __ctype_b

[Daniel Jacobowitz]

On Mon, Dec 02, 2002 at 12:21:50PM -0800, Roland McGrath wrote:
 I'm not sure exactly what you are asking.
 
 What makes old static binaries crash when they try to load a new libc.so is
 an old bug in the dynamic loading code when handling a reference within an
 object to a hidden symbol in the same object.  That was fixed by this change:
 
 2002-09-18  Roland McGrath  [EMAIL PROTECTED]
 
   * elf/do-rel.h (elf_dynamic_do_rel): Mask off 0x8000 bit (hidden flag)
   from the value taken from the DT_VERSYM table.
   * elf/dl-runtime.c (fixup, profile_fixup): Likewise.
   * sysdeps/mips/dl-machine.h (__dl_runtime_resolve): Likewise.
   (RESOLVE_GOTSYM): Likewise.
 
 Obviously, existing static binaries will continue to have that bug.  It
 makes them crash when they come across such a symbol.  In stock 2.3.1,
 __ctype_b et al are such symbols because they are not exported at link time.
 The compat_symbol uses are what prevent the link-time export (in nm output,
 you can see [EMAIL PROTECTED] vs __ctype_b@@GLIBC_2.0 and the like;
 in objdump --dynamic-syms output you can see GLIBC_2.0 vs (GLIBC_2.0)).
 
 In the RHL version of glibc, those symbols are exported again by omitting
 the compat_symbol uses.  The both avoids tickling the aforementioned bug,
 and also lets existing .a's and .o's compiled with the old ctype.h be
 usable.  If you want to do that, just comment out the compat_symbol's.

I suppose what really confuses me is that the compat_symbol entries for
__ctype_* are commented out in RHL glibc, but not for __ctype32_*. 
Why the asymmetry?

With the __ctype32_* ones present, I don't see how to both:
 - Avoid the crash in old static linkers
 - Handle application  R_*_COPY relocs correctly for __ctype32_*.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Re: RH glibc and __ctype_b

[Roland McGrath]

 I suppose what really confuses me is that the compat_symbol entries for
 __ctype_* are commented out in RHL glibc, but not for __ctype32_*. 
 Why the asymmetry?

In the current RHL glibc sources, both are treated the same.

Sucess/problems with libc6-i686

[David Schleef]

I've been playing with building and using the libc6-i686 package
recently, mainly to help track down a Red Hat bug.

A few little problems I noticed:

 - I think the .postinst is really supposed to be the .postrm

 - libc6-i686 contains /lib/ld-linux.so.2, which conflicts with
   libc6.  Simply removing this file from the packge make it work.
 
 - The default CFLAGS is -O99 -fomit-frame-pointer
   -D__USE_STRING_INLINES.  I'm not sure if this is upstream's
   idea of a joke or what, but it causes massive instability in
   pthreads.  -O2 works fine.  -O3 causes subtle problems that
   I've been seeing in Red Hat 8.0's package.  (Corruption in
   pthread's data structures.)

After fixing those, it seems to be rather stable.

I wish I could say that I see massive performance improvements, but
I don't.



dave...

Re: RH glibc and __ctype_b

[Daniel Jacobowitz]

On Mon, Dec 02, 2002 at 12:32:33PM -0800, Roland McGrath wrote:
  I suppose what really confuses me is that the compat_symbol entries for
  __ctype_* are commented out in RHL glibc, but not for __ctype32_*. 
  Why the asymmetry?
 
 In the current RHL glibc sources, both are treated the same.

That'll teach me - I looked at RHL 8.0 instead of rawhide, and so did
GOTO.  Thanks.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

cvs commit to glibc-package/debian/patches by dan

[Debian GLibc CVS Master]

Repository: glibc-package/debian/patches
who:dan
time:   Mon Dec  2 15:34:31 MST 2002
Log Message:
  - Update glibc23-ctype-compat.patch to fix segfaults in old static
binaries (Closes: #171451).
  

Files:
changed:glibc23-ctype-compat.dpatch

Re: RH glibc and __ctype_b

[Jakub Jelinek]

On Mon, Dec 02, 2002 at 03:29:17PM -0500, Daniel Jacobowitz wrote:
  In the RHL version of glibc, those symbols are exported again by omitting
  the compat_symbol uses.  The both avoids tickling the aforementioned bug,
  and also lets existing .a's and .o's compiled with the old ctype.h be
  usable.  If you want to do that, just comment out the compat_symbol's.
 
 I suppose what really confuses me is that the compat_symbol entries for
 __ctype_* are commented out in RHL glibc, but not for __ctype32_*. 
 Why the asymmetry?

__ctype_* was changed because we had lots of .a files in the distro when
the __ctype* changes happened and it was too late to recompile them all.
We had no __ctype32_* that I could find, hence I left what was
in glibc CVS for these. Old binaries/libraries should run fine (with
exception of statically linked progs) and newly compiled ones will use
__ctype*_loc instead.

Jakub

Re: bugs triage?

[Carlos O'Donell]

  Package: glibc; Severity: serious; Reported by: Branden Robinson [EMAIL 
  PROTECTED]; Tags: help.
  
  Carlos is looking at this one I think.
 
 Carlos?
 
 -- gotom
 

I'm working on it. I'm entering examination period in university and my
time is disappearing. I'm fixing a fesetround() that was just seen on
HP's test-drive systems (getting more testing is great!).

When are we aiming for a -5?

c.

Re: bugs triage?

[Daniel Jacobowitz]

On Mon, Dec 02, 2002 at 05:45:43PM -0500, Carlos O'Donell wrote:
   Package: glibc; Severity: serious; Reported by: Branden Robinson [EMAIL 
   PROTECTED]; Tags: help.
   
   Carlos is looking at this one I think.
  
  Carlos?
  
  -- gotom
  
 
 I'm working on it. I'm entering examination period in university and my
 time is disappearing. I'm fixing a fesetround() that was just seen on
 HP's test-drive systems (getting more testing is great!).
 
 When are we aiming for a -5?

It'll be -6, and pretty soon.  Jeff's doing the CVS patch right now...

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Bug#171502: locales: improve localization of locales.templates

[Denis Barbier]

Package: locales
Version: 2.3.1-5
Severity: minor
Tags: patch

Hi,

strings Leave alone and None are hardcoded and cannot be localized
in the templates file.  Here is a patch 

Denis

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux france0danemark2 2.4.18-386 #2 Sun Apr 14 10:38:08 EST 2002 i586
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set)

Versions of packages locales depends on:
ii  debconf   1.2.16 Debian configuration management sy
ii  libc6 [glibc-2.3.1-5] 2.3.1-5GNU C Library: Shared libraries an

-- debconf information excluded

Index: config
===
RCS file: /cvs/glibc/glibc-package/debian/locales/DEBIAN/config,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 config
--- config  25 Jul 2002 14:37:00 -  1.1.1.1
+++ config  2 Dec 2002 22:48:59 -
@@ -23,7 +23,11 @@
 
 db_get locales/locales_to_be_generated  DEFAULT_LOCALES=$(echo $RET | sed -e 
's/ [^ ]*,/,/g' -e 's/ [^ ]*$//')
 
-test -z $DEFAULT_LOCALES || DEFAULT_LOCALES=, $DEFAULT_LOCALES
-db_subst locales/default_environment_locale locales Leave alone, None, 
C$DEFAULT_LOCALES
+if test -z $DEFAULT_LOCALES; then
+DEFAULT_LOCALES=C
+else
+DEFAULT_LOCALES=C, $DEFAULT_LOCALES
+fi
+db_subst locales/default_environment_locale locales $DEFAULT_LOCALES
 db_input medium locales/default_environment_locale || true
 db_go
Index: templates
===
RCS file: /cvs/glibc/glibc-package/debian/locales/DEBIAN/templates,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 templates
--- templates   25 Jul 2002 14:37:00 -  1.1.1.1
+++ templates   2 Dec 2002 22:48:59 -
@@ -1,6 +1,6 @@
 Template: locales/locales_to_be_generated
 Type: multiselect
-Choices: ${locales}
+Choices: Leave alone, None, ${locales}
 Description: Select locales to be generated.
  You can choose locales to be generated by selecting locales you want.
  Selected locales will be saved to `/etc/locale.gen' file. You can also

Re: bugs triage?

[Randolph Chung]

 I'm working on it. I'm entering examination period in university and my
 time is disappearing. I'm fixing a fesetround() that was just seen on
 HP's test-drive systems (getting more testing is great!).

let me know if i can help :-)
randolph

cvs commit to glibc-package/debian by dan

[Debian GLibc CVS Master]

Repository: glibc-package/debian
who:dan
time:   Mon Dec  2 19:00:19 MST 2002
Log Message:
  - Allow building from the CVS checkout without getting CVS dirs in the
resulting packages.  Whew.
  

Files:
changed:changelog

cvs commit to glibc-package/debian/packages.d by dan

[Debian GLibc CVS Master]

Repository: glibc-package/debian/packages.d
who:dan
time:   Mon Dec  2 19:00:19 MST 2002
Log Message:
  - Allow building from the CVS checkout without getting CVS dirs in the
resulting packages.  Whew.
  

Files:
changed:glibc-doc.mk libc-dbg.mk libc-dev.mk libc-pic.mk libc-prof.mk 
libc-udeb.mk libc.mk locales.mk nscd.mk optimized.mk s390x.mk sparc64.mk

[PATCH] Make sure kernel is recent when installing on HPPA

[Carlos O'Donell]

debian-glibc,

I've seen one person get burned by this, so I was thinking of 
something along the lines of the Sparc test in preinst that checks
to see if the kernel version is the minimum required for glibc.

Comments?

c.

--- debian/libc/DEBIAN/preinst.orig 2002-12-02 20:21:46.0 -0500
+++ debian/libc/DEBIAN/preinst  2002-12-02 20:31:16.0 -0500
@@ -100,6 +100,19 @@
fi
fi
 fi
+# HPPA boxes require latest fixes in the kernel to function properly.
+if [ $realarch = parisc64 ] || [ $realarch = parisc ]
+then
+   kernel_ver=`uname -r`
+   if dpkg --compare-versions $kernel_ver lt 2.4.19
+   then
+   echo WARNING: This version of libc6 requires that you be running
+   echo atleast a 2.4.19 kernel in order to work properly. Earlier
+   echo kernels did not provide the proper functionality in order 
+   echo for the system to be stable. 
+   exit 1
+   fi
+fi
 fi
 
 exit 0

[PATCH] fesetround() bug fixed in hppa

[Carlos O'Donell]

  I'm working on it. I'm entering examination period in university and my
  time is disappearing. I'm fixing a fesetround() that was just seen on
  HP's test-drive systems (getting more testing is great!).
 
 let me know if i can help :-)
 randolph

Fixed. Dpatch attached :)

c.

#! /bin/sh -e

# DP: Description: Corrects error in fesetround() when clearning FPU rounding 
mask. 
# DP: Author: Carlos O'Donell [EMAIL PROTECTED]
# DP: Upstream status: Submitted
# DP: Status: Details: Awaiting to hear from upstream.
# DP: Date: Monday December 2, 2002

if [ $# -ne 2 ]; then
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
fi
case $1 in
-patch) patch -d $2 -f --no-backup-if-mismatch -p1  $0;;
-unpatch) patch -d $2 -f --no-backup-if-mismatch -R -p1  $0;;
*)
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
esac
exit 0

# append the patch here and adjust the -p? flag in the patch calls.
--- glibc-2.3.1/sysdeps/hppa/fpu/fesetround.c   2002-12-02 16:36:36.0 
-0500
+++ glibc-2.3.1/sysdeps/hppa/fpu/fesetround.c   2002-12-02 16:36:59.0 
-0500
@@ -31,7 +31,7 @@
 
   /* Get the current status word. */
   __asm__ (fstd %%fr0,0(%1) : =m (*sw) : r (sw));
-  sw[0] = ~FE_UPWARD;
+  sw[0] = ~FE_DOWNWARD;
   sw[0] |= round;
   __asm__ (fldd 0(%0),%%fr0 : : r (sw));
 

[PATCH] fix masking error in fesetround() on hppa

[Carlos O'Donell]

libc-alpha,

Thanks to HP's testdrive users, we found and fixed a small masking bug
in fesetround(). Should use ~FE_DOWNWARD since this is the rounding mask
set to all ones, and will clear the mask before or'ing the round value.

It was suggested that a test case could be made of this, where glibc
tries to set and get various combinations of FE_DOWNWARD, FE_UPWARD,
FE_TONEAREST, and FE_UPWARD. I could provide such a testcase if it was
deemed usefull. 

c.

---

2002-12-02  Carlos O'Donell  [EMAIL PROTECTED]

* sysdeps/hppa/fpu/fesetround.c: 
(fesetround): Use ~FE_DOWNWARD so both bits of RM are cleared.
--- glibc-2.3.1/sysdeps/hppa/fpu/fesetround.c   2002-12-02 16:36:36.0 
-0500
+++ glibc-2.3.1/sysdeps/hppa/fpu/fesetround.c   2002-12-02 16:36:59.0 
-0500
@@ -31,7 +31,7 @@
 
   /* Get the current status word. */
   __asm__ (fstd %%fr0,0(%1) : =m (*sw) : r (sw));
-  sw[0] = ~FE_UPWARD;
+  sw[0] = ~FE_DOWNWARD;
   sw[0] |= round;
   __asm__ (fldd 0(%0),%%fr0 : : r (sw));
 

Re: [PATCH] fix masking error in fesetround() on hppa

[Roland McGrath]

I've put that fix in.  I'm not quite sure what you are suggesting for a new
test, but test cases that fail on known bug regressions (i.e. one that
fails before your fix and works after it) are always welcome.


Thanks,
Roland

Re: [PATCH] Make sure kernel is recent when installing on HPPA

[Carlos O'Donell]

 --- debian/libc/DEBIAN/preinst.orig   2002-12-02 20:21:46.0 -0500
 +++ debian/libc/DEBIAN/preinst2002-12-02 20:31:16.0 -0500
 @@ -100,6 +100,19 @@
   fi
   fi
  fi
 +# HPPA boxes require latest fixes in the kernel to function properly.
 +if [ $realarch = parisc64 ] || [ $realarch = parisc ]
 +then
 + kernel_ver=`uname -r`
 + if dpkg --compare-versions $kernel_ver lt 2.4.19
 + then
 + echo WARNING: This version of libc6 requires that you be running
 + echo atleast a 2.4.19 kernel in order to work properly. Earlier
 + echo kernels did not provide the proper functionality in order 
 + echo for the system to be stable. 
 + exit 1
 + fi
 +fi
  fi
  
  exit 0


Built and tested deb's on PA using this patch and it all works.
This should be included in the -6 release.

c.

Re: [PATCH] fesetround() bug fixed in hppa

[Carlos O'Donell]

 #! /bin/sh -e
 
 # DP: Description: Corrects error in fesetround() when clearning FPU rounding 
 mask. 
 # DP: Author: Carlos O'Donell [EMAIL PROTECTED]
 # DP: Upstream status: Submitted
 ^ 
 Accepted.

 # DP: Status: Details: Awaiting to hear from upstream.
 ^^^ 
 Applied upsream.  

 # DP: Date: Monday December 2, 2002


This may be the first time in history where I generate a dpatch and it
never gets used because upstream was in sync before we made the
cvs.dpatch :)

c.