Bug#242122: No weak symbol for res_* on amd64.
On Sun, Apr 04, 2004 at 07:26:18PM -0400, Daniel Jacobowitz wrote: > On Mon, Apr 05, 2004 at 12:32:29AM +0200, Kurt Roeckx wrote: > > > > It's a problem because configure doesn't find it anymore. It > > doesn't include resolv.h so it doesn't know that it gets changed > > to __res_*. > > That's a bug in the affected configure scripts, then. I believe > autoconf 2.5x is capable of handling this correctly. Openssh 3.8p1-2 is using autoconf 2.52 and has the problem, krb5 1.3.2 is even using 2.59. krb5 for instance returns this: checking for res_search... no checking for res_search in -lresolv... no configure: error: Cannot find resolver support routine res_search in -lresolv. make: *** [configure-stamp] Error 1 The test program looks like: | char res_search (); | int | main () | { | res_search (); | ; | return 0; | } Without resolv.h it will not find __res_search, with resolv.h it will fail to compile because of "too few arguments to function". Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#242122: No weak symbol for res_* on amd64.
On Mon, Apr 05, 2004 at 12:32:29AM +0200, Kurt Roeckx wrote: > On Sun, Apr 04, 2004 at 06:22:57PM -0400, Daniel Jacobowitz wrote: > > On Sun, Apr 04, 2004 at 11:50:15PM +0200, Kurt Roeckx wrote: > > > Package: libc6 > > > Version: 2.3.2.ds1-11 > > > > > > It seems the weak symbols for res_* are missing on amd64. > > > > > > in resolv/res_data.c there is: > > > #if SHLIB_COMPAT(libresolv, GLIBC_2_0, GLIBC_2_2) > > > weak_alias (__res_query, res_query); > > > > > > It seems the "SHLIB_COMPAT(libresolv, GLIBC_2_0, GLIBC_2_2)" > > > returns false for some reason. If I remove that #if then I > > > properly get the weak symbols. > > > > Why do you believe the weak symbols should be there? > > It's a problem because configure doesn't find it anymore. It > doesn't include resolv.h so it doesn't know that it gets changed > to __res_*. > > I see 2 ways of fixing this, either fix all packages that depend > on libresolv or add the weak symbols. > > > PS: I've also found this post: > http://mail.gnu.org/archive/html/bug-hurd/2002-05/msg00256.html That's a bug in the affected configure scripts, then. I believe autoconf 2.5x is capable of handling this correctly. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#242122: No weak symbol for res_* on amd64.
On Sun, Apr 04, 2004 at 06:22:57PM -0400, Daniel Jacobowitz wrote: > On Sun, Apr 04, 2004 at 11:50:15PM +0200, Kurt Roeckx wrote: > > Package: libc6 > > Version: 2.3.2.ds1-11 > > > > It seems the weak symbols for res_* are missing on amd64. > > > > in resolv/res_data.c there is: > > #if SHLIB_COMPAT(libresolv, GLIBC_2_0, GLIBC_2_2) > > weak_alias (__res_query, res_query); > > > > It seems the "SHLIB_COMPAT(libresolv, GLIBC_2_0, GLIBC_2_2)" > > returns false for some reason. If I remove that #if then I > > properly get the weak symbols. > > Why do you believe the weak symbols should be there? It's a problem because configure doesn't find it anymore. It doesn't include resolv.h so it doesn't know that it gets changed to __res_*. I see 2 ways of fixing this, either fix all packages that depend on libresolv or add the weak symbols. PS: I've also found this post: http://mail.gnu.org/archive/html/bug-hurd/2002-05/msg00256.html Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#242122: No weak symbol for res_* on amd64.
On Sun, Apr 04, 2004 at 11:50:15PM +0200, Kurt Roeckx wrote: > Package: libc6 > Version: 2.3.2.ds1-11 > > It seems the weak symbols for res_* are missing on amd64. > > in resolv/res_data.c there is: > #if SHLIB_COMPAT(libresolv, GLIBC_2_0, GLIBC_2_2) > weak_alias (__res_query, res_query); > > It seems the "SHLIB_COMPAT(libresolv, GLIBC_2_0, GLIBC_2_2)" > returns false for some reason. If I remove that #if then I > properly get the weak symbols. Why do you believe the weak symbols should be there? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#242122: No weak symbol for res_* on amd64.
Package: libc6 Version: 2.3.2.ds1-11 It seems the weak symbols for res_* are missing on amd64. in resolv/res_data.c there is: #if SHLIB_COMPAT(libresolv, GLIBC_2_0, GLIBC_2_2) weak_alias (__res_query, res_query); It seems the "SHLIB_COMPAT(libresolv, GLIBC_2_0, GLIBC_2_2)" returns false for some reason. If I remove that #if then I properly get the weak symbols. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#183143: this bug breaks d-i
On Sat, Apr 03, 2004 at 11:38:30AM +0900, GOTO Masanori wrote: > > The packages depends against libc6 (or what the shlibs file says), but > > there is nothing which can be resolved as libc6. > > > > Please don't try to argue, that versioned provides can't be resolved. > > This is only true for real packages, not for udeb which aren't covered > > by the policy. > Which packages specifically? I would like to know how to reproduce > the problem and what the real problem is... | debian-installer/trunk/packages$ grep "Depends: \${shlib" -r . | awk -F '/' '{print $2;}' | uniq | sort | arch | base-installer | cdebconf | choose-mirror | debian-installer-utils | kbd-chooser | libdebian-installer | main-menu | netcfg | partconf | partitioner | udpkg This bug makes it impossible to release some of our software as it will break anything. You have time to fix it until wednesday, 6.4.2004. Bastian -- One does not thank logic. -- Sarek, "Journey to Babel", stardate 3842.4 signature.asc Description: Digital signature
Processed: Re: Bug#241996:
Processing commands for [EMAIL PROTECTED]: > reassign 241996 ssh Bug#241996: Bug reassigned from package `libc6.1' to `ssh'. > severity 241996 important Bug#241996: Severity set to `important'. > merge 23 241996 Bug#23: Read from socket failed on Alpha Bug#241996: Merged 23 241996. > 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]
Re: Bug#235759: Comentar on which replacement for German quotes
GOTO Masanori wrote: > At Mon, 29 Mar 2004 04:23:37 -0500, > Nathanael Nerode wrote: >> > as a German native speaker with some interest on typography but >> > virtually no knowledge on UTF-8 some comments: >> > >> > The common quotes in German today are >> > double open quotes (low position) U201E >> > together with >> > double closed quote (high position) U201C >> > >> > The current conversion >> > ,,text" >> > looks strange because the opening quotes don't match the closing >> > quotes. >> I would make an effort to avoid any conversion which is asymmetrical in >> length, for any language, actually. I hate when info documents say >> ``foo", for instance... > > So are ,,text'' and ``foo'' reasonable? Well, although I said "no", I admit that they are better than ,,text" and ``foo", because they don't have the asymmetry... They are unreasonable, however, for *different* reasons. In English, "foo" should be used when curly quotes are unavailable, not ``foo''. ("`" and "'" make a crummy pair of quotes, even though TeX uses them.) In German, >>foo<< (or was it <> ?) should be used when the curly quotes are unavailable (using real guillemets, not greater-than and less-than signs), as all the Germans were saying. ,,text'' might be reasonable if the guillemets aren't available, but >>foo<< (or was it <>?) might be better because it's less likely to be confusing -- and "foo" might be the best of all, because it's almost certainly not confusing. The point is that retaining meaning should take priority over retaining appearance. The current conversions attempt to retain a sort of parody of the appearance, but are worse at retaining meaning than the alternative suggested conversions. Imagine if the default conversion for kanji and kana was ASCII art, and you'll get an idea of why the current conversion just seems wrong (though it isn't *that* bad). -- Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *** VIRUS ALERT *** Re: Your product
From: [EMAIL PROTECTED] Subject: Message non lu ! Pour nous contacter, veuillez SVP utiliser notre messagerie en ligne sur le site: http://www.astroo.com Merci. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#241996:
reassign 241996 ssh severity 241996 important merge 23 241996 thanks On Sun, Apr 04, 2004 at 05:56:18PM +0200, Ronny Vaningh wrote: > I was quite sure that I saw libc mentioned as an updated package some > days ago ... > > I keep the box up to date with apt quite regulary > > The funky thing is that I upgraded the kernel to the 2.4.25 (-1-generic > as packaged) and that this seemed to solve my ssh problem as well. Yes, that's not surprising at all. The problem is ssh not coping gracefully with the setresuid() and setresgid() system calls being missing, and they aren't missing in 2.4.25. I was wondering why this failure seemed to be new, but the use of setres[ug]id() is new in OpenSSH 3.7, which would explain it. I bet the upgrade you noticed also included an upgrade from ssh 3.6-* to 3.8-*. Normally I'd request that glibc provide compatibility stubs, but I don't think that's possible for setres[ug]id(), so ssh just has to deal with it. > We have another box with the same architecture (norritake) running > testing and had no problems with the ssh on the box, but this one was > already running a 2.4 kernel for a long time > > I know this is not what I would call sufficient info ... sorry Oh well; thanks anyway. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#241996:
On Sun, Apr 04, 2004 at 10:18:12AM +0200, Ronny Vaningh wrote: > Package: libc6.1 > Version: 2.3.2.ds1-11 > > I cannot ssh to the box anymore after upgrading libc > Running sshd in debug results in > > debug1: permanently_set_uid: 100/65534 > setresgid 65534: Function not implemented > debug1: do_cleanup > > I have the same package versions of libC and ssh on a alpha box running > a 2.4 kernel, without encountering any problems I think this is bug #23, which I'll be fixing in openssh shortly. However, I'm interested that it occurred following a libc6.1 upgrade. What version of libc6.1 did you have beforehand? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#241667: marked as done (gcc-3.3: __attribute_const__ fail)
Your message dated Sun, 4 Apr 2004 12:26:29 +0200 with message-id <[EMAIL PROTECTED]> and subject line Bug#241667: gcc-3.3: __attribute_const__ fail 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 Apr 2004 10:09:18 + >From [EMAIL PROTECTED] Fri Apr 02 02:09:18 2004 Return-path: <[EMAIL PROTECTED]> Received: from master.debian.org [146.82.138.7] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1B9Lby-0001y8-00; Fri, 02 Apr 2004 02:09:18 -0800 Received: from relax.gwarbit.pl ([127.0.0.1]) [195.205.32.194] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1B9Lbw-0004ef-00; Fri, 02 Apr 2004 04:09:16 -0600 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Marcin Kurek <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: gcc-3.3: __attribute_const__ fail X-Mailer: reportbug 2.56 Date: Fri, 02 Apr 2004 12:09:13 +0200 X-Debbugs-Cc: [EMAIL PROTECTED] Message-Id: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-7.5 required=4.0 tests=BAYES_01,HAS_PACKAGE, OUR_MTA_MSGID,X_DEBBUGS_CC autolearn=ham version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: Package: gcc-3.3 Version: 1:3.3.3-5 Severity: important I am not completly shure is that a real bug, but it is a problem at all. it seems __attribute_const__ cause a parse error in current Debian release. And such construction can be found in many kernel 2.6.4 header files and in some projects too. For example in /include/linux/byteorder/swab.h in __fswab32 and __fswab16 functions. This error makes impossible to compile MPlayer for example (At last without small header tunes) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.4-destruction Locale: LANG=C, LC_CTYPE=C Versions of packages gcc-3.3 depends on: ii binutils 2.14.90.0.7-6 The GNU assembler, linker and bina ii cpp-3.31:3.3.3-5 The GNU C preprocessor ii gcc-3.3-base 1:3.3.3-5 The GNU Compiler Collection (base ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libgcc11:3.3.3-5 GCC support library -- no debconf information --- Received: (at 241667-done) by bugs.debian.org; 4 Apr 2004 10:27:37 + >From [EMAIL PROTECTED] Sun Apr 04 03:27:37 2004 Return-path: <[EMAIL PROTECTED]> Received: from mx4.informatik.uni-tuebingen.de [134.2.12.29] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1BA4qm-0003fM-00; Sun, 04 Apr 2004 03:27:37 -0700 Received: from localhost (loopback [127.0.0.1]) by mx4.informatik.uni-tuebingen.de (Postfix) with ESMTP id 5E244135F; Sun, 4 Apr 2004 12:27:05 +0200 (MST) Received: from mx4.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx4 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19694-01; Sun, 4 Apr 2004 12:26:30 +0200 (DFT) Received: from joseki.informatik.uni-tuebingen.de (joseki.Informatik.Uni-Tuebingen.De [134.2.15.82]) by mx4.informatik.uni-tuebingen.de (Postfix) with ESMTP id B6D75132C; Sun, 4 Apr 2004 12:26:29 +0200 (MST) Received: (from [EMAIL PROTECTED]) by joseki.informatik.uni-tuebingen.de (8.11.7+Sun/8.11.7) id i34AQTl03418; Sun, 4 Apr 2004 12:26:29 +0200 (MEST) Date: Sun, 4 Apr 2004 12:26:29 +0200 From: Falk Hueffner <[EMAIL PROTECTED]> To: Marcin Kurek <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: Bug#241667: gcc-3.3: __attribute_const__ fail Message-ID: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <[EMAIL PROTECTED]> User-Agent: Mutt/1.4i Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-5.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: X-CrossAssassin-Scores: 1 On Sat, Apr 03, 2004 at 11:00:06AM +0200, Marcin Kurek wrote: > I use a normal link to set my
Bug#241996:
Package: libc6.1 Version: 2.3.2.ds1-11 I cannot ssh to the box anymore after upgrading libc Running sshd in debug results in debug1: permanently_set_uid: 100/65534 setresgid 65534: Function not implemented debug1: do_cleanup I have the same package versions of libC and ssh on a alpha box running a 2.4 kernel, without encountering any problems -- System Information: Debian Release: testing/unstable Architecture: alpha Kernel: 2.2.20 #2 Wed Mar 20 19:57:28 EST 2002 alpha GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]