Bug#229461: libc6 - fails to install - uses awk in preinst

2004-02-15 Thread Anthony Towns
> On Sat, Jan 24, 2004 at 09:31:37PM -0500, Jeff Bailey wrote: > > Can you give me the steps to reproduce? > Unpack libc6 before mawk is configured. mawk depends against libc6. mawk is essential, you cannot unpack libc6 until mawk is working effectively. That's what bootstrapping is all about. On

Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols

2004-02-15 Thread Andrew Suffield
On Sun, Feb 15, 2004 at 03:27:40PM -0500, Daniel Jacobowitz wrote: > On Sun, Feb 15, 2004 at 01:55:46PM -0600, Steve Langasek wrote: > > Package: libc6 > > Version: 2.3.2.ds1-11 > > > > It appears that, given: > > > > library libbar, providing version BAR1 of symbol bar_sym1; > > library libquux,

Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols

2004-02-15 Thread Daniel Jacobowitz
On Sun, Feb 15, 2004 at 09:15:05PM +, Andrew Suffield wrote: > Hmm, how about only doing this for things picked up via LD_PRELOAD? > It's really *nasty* for regular libraries. All I know is that I'm not touching lookup behavior with a thousand yard stick for Debian specifically. If you don't

Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols

2004-02-15 Thread Daniel Jacobowitz
On Sun, Feb 15, 2004 at 01:55:46PM -0600, Steve Langasek wrote: > Package: libc6 > Version: 2.3.2.ds1-11 > > It appears that, given: > > library libbar, providing version BAR1 of symbol bar_sym1; > library libquux, linked against libbar and using (version BAR1 of) bar_sym1; > and program foo, lin

Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols

2004-02-15 Thread Steve Langasek
Package: libc6 Version: 2.3.2.ds1-11 It appears that, given: library libbar, providing version BAR1 of symbol bar_sym1; library libquux, linked against libbar and using (version BAR1 of) bar_sym1; and program foo, linked with -rdynamic, providing unversioned symbol bar_sym1, and dlopen()ing lib

Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols

2004-02-15 Thread Andrew Suffield
On Sun, Feb 15, 2004 at 03:27:40PM -0500, Daniel Jacobowitz wrote: > On Sun, Feb 15, 2004 at 01:55:46PM -0600, Steve Langasek wrote: > > Package: libc6 > > Version: 2.3.2.ds1-11 > > > > It appears that, given: > > > > library libbar, providing version BAR1 of symbol bar_sym1; > > library libquux,

Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols

2004-02-15 Thread Daniel Jacobowitz
On Sun, Feb 15, 2004 at 09:15:05PM +, Andrew Suffield wrote: > Hmm, how about only doing this for things picked up via LD_PRELOAD? > It's really *nasty* for regular libraries. All I know is that I'm not touching lookup behavior with a thousand yard stick for Debian specifically. If you don't

Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols

2004-02-15 Thread Daniel Jacobowitz
On Sun, Feb 15, 2004 at 01:55:46PM -0600, Steve Langasek wrote: > Package: libc6 > Version: 2.3.2.ds1-11 > > It appears that, given: > > library libbar, providing version BAR1 of symbol bar_sym1; > library libquux, linked against libbar and using (version BAR1 of) bar_sym1; > and program foo, lin

Bug#231972: lkh: /usr/include/linux/ptrace.h buggy

2004-02-15 Thread Christoph Hellwig
On Sun, Feb 15, 2004 at 01:48:10PM +0100, Petter Reinholdtsen wrote: > I assume that all glibc headers should be compilable when using 'gcc > -ansi'. is not part of ANSI C/C++ so this is a broken assumption. Really guys, there's seldomly a reason to use -ansi as you're most probably _not_ trying

Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols

2004-02-15 Thread Steve Langasek
Package: libc6 Version: 2.3.2.ds1-11 It appears that, given: library libbar, providing version BAR1 of symbol bar_sym1; library libquux, linked against libbar and using (version BAR1 of) bar_sym1; and program foo, linked with -rdynamic, providing unversioned symbol bar_sym1, and dlopen()ing lib

Bug#232891: glibc: Include Danish debconf translation

2004-02-15 Thread Claus Hindsgaul
Package: glibc Severity: wishlist Tags: patch l10n Please include the attached Danish debconf translation. # translation of da.po to Danish # translation of glibc Debian debconf template to Danish # Claus Hindsgaul <[EMAIL PROTECTED]>, 2004. # msgid "" msgstr "" "Project-Id-Version: da\n" "Report

Bug#231972: lkh: /usr/include/linux/ptrace.h buggy

2004-02-15 Thread Christoph Hellwig
On Sun, Feb 15, 2004 at 01:48:10PM +0100, Petter Reinholdtsen wrote: > I assume that all glibc headers should be compilable when using 'gcc > -ansi'. is not part of ANSI C/C++ so this is a broken assumption. Really guys, there's seldomly a reason to use -ansi as you're most probably _not_ trying

Bug#231972: lkh: /usr/include/linux/ptrace.h buggy

2004-02-15 Thread Christoph Hellwig
On Sun, Feb 15, 2004 at 05:02:10PM +0200, Riku Voipio wrote: > Noticed that ksysguardd includes only to > get PAGE_SIZE. > > other apps seem to use for that? Is using that > ansi safe on all platforms? Both are wrong. Use sysconf(_SC_PAGESIZE) instead.

Bug#231972: lkh: /usr/include/linux/ptrace.h buggy

2004-02-15 Thread Riku Voipio
Noticed that ksysguardd includes only to get PAGE_SIZE. other apps seem to use for that? Is using that ansi safe on all platforms? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo|

Bug#232891: glibc: Include Danish debconf translation

2004-02-15 Thread Claus Hindsgaul
Package: glibc Severity: wishlist Tags: patch l10n Please include the attached Danish debconf translation. # translation of da.po to Danish # translation of glibc Debian debconf template to Danish # Claus Hindsgaul <[EMAIL PROTECTED]>, 2004. # msgid "" msgstr "" "Project-Id-Version: da\n" "Report

Bug#231972: lkh: /usr/include/linux/ptrace.h buggy

2004-02-15 Thread Christoph Hellwig
On Sun, Feb 15, 2004 at 05:02:10PM +0200, Riku Voipio wrote: > Noticed that ksysguardd includes only to > get PAGE_SIZE. > > other apps seem to use for that? Is using that > ansi safe on all platforms? Both are wrong. Use sysconf(_SC_PAGESIZE) instead. -- To UNSUBSCRIBE, email to [EMAIL PR

Bug#231972: lkh: /usr/include/linux/ptrace.h buggy

2004-02-15 Thread Riku Voipio
Noticed that ksysguardd includes only to get PAGE_SIZE. other apps seem to use for that? Is using that ansi safe on all platforms? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo|

Bug#231972: lkh: /usr/include/linux/ptrace.h buggy

2004-02-15 Thread Petter Reinholdtsen
Here is more info on the problem. The issue is that 'struct user' in on s390 need 'struct user_regs_struct' from , and this need type 's390_fp_regs' which need type 'freq_t' which need type '__u64' which is unavailable when compiling with -ansi. The reason the '__u64' type is mising is that ANS

Bug#231972: lkh: /usr/include/linux/ptrace.h buggy

2004-02-15 Thread Petter Reinholdtsen
I had a look at this on raptor.debian.org (dchroot unstable). The triggering code seem to be in in /usr/include/asm/types.h: #ifndef __s390x__ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) typedef __signed__ long long __s64; typedef unsigned long long __u64; #endif #else /* __s3

Bug#231972: lkh: /usr/include/linux/ptrace.h buggy

2004-02-15 Thread Petter Reinholdtsen
Here is more info on the problem. The issue is that 'struct user' in on s390 need 'struct user_regs_struct' from , and this need type 's390_fp_regs' which need type 'freq_t' which need type '__u64' which is unavailable when compiling with -ansi. The reason the '__u64' type is mising is that ANS

Bug#223846: [mips/s390] FTBFS: linux/mod_devicetable.h errors - seems fixed

2004-02-15 Thread Riku Voipio
This bug seems gone, kdeadmin 3.1.5 has compiled fine on mips and s/390: http://buildd.debian.org/fetch.php?&pkg=kdeadmin&ver=4%3A3.1.5-1&arch=mips&stamp=1074004757&file=log&as=raw There is no s/390 buildd log, but the packages are on the mirrors, so presumably someone compiled them by hand. t

Bug#231972: lkh: /usr/include/linux/ptrace.h buggy

2004-02-15 Thread Petter Reinholdtsen
I had a look at this on raptor.debian.org (dchroot unstable). The triggering code seem to be in in /usr/include/asm/types.h: #ifndef __s390x__ #if defined(__GNUC__) && !defined(__STRICT_ANSI__) typedef __signed__ long long __s64; typedef unsigned long long __u64; #endif #else /* __s3

Bug#223846: [mips/s390] FTBFS: linux/mod_devicetable.h errors - seems fixed

2004-02-15 Thread Riku Voipio
This bug seems gone, kdeadmin 3.1.5 has compiled fine on mips and s/390: http://buildd.debian.org/fetch.php?&pkg=kdeadmin&ver=4%3A3.1.5-1&arch=mips&stamp=1074004757&file=log&as=raw There is no s/390 buildd log, but the packages are on the mirrors, so presumably someone compiled them by hand. t