Re: Help needed with eglibc 2.13
On Sun, Mar 27, 2011 at 02:40:45PM -0600, dann frazier wrote: On Sat, Mar 26, 2011 at 04:52:32PM +0100, Aurelien Jarno wrote: On Fri, Mar 25, 2011 at 01:48:30PM -0600, dann frazier wrote: On Sat, Mar 19, 2011 at 02:03:00PM +0100, Aurelien Jarno wrote: Hi alpha porters, I am trying to get eglibc 2.13 ready to get uploaded into unstable. I have done the missing porting work on alpha, but I am now stuck with testsuite regressions, and I would need help to fix them. First of all paer.debian.org, and the machine on the ESIEE cluster I am using is still running a 2.6.22 kernel, which is too old for the minimum kernel version we are targeting for wheezy (2.6.26). I would appreciate if I can get access to a machine running a 2.6.26+ kernel. fyi, paer is running 2.6.26... it hasn't ran anything older for years (though it was running 2.6.32 until the recent reinstall). dannf@paer:~$ uname -a Linux paer 2.6.26-2-parisc64-smp #1 SMP Thu Feb 3 10:23:00 UTC 2011 parisc64 GNU/Linux Thanks, 2.6.26 is find enough. Could you please create a sid chroot on this machine? I've requested this in RT #3081 Which was just resolved. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110331214501.ga19...@dannf.org
Re: Help needed with eglibc 2.13
On Sat, Mar 26, 2011 at 04:52:32PM +0100, Aurelien Jarno wrote: On Fri, Mar 25, 2011 at 01:48:30PM -0600, dann frazier wrote: On Sat, Mar 19, 2011 at 02:03:00PM +0100, Aurelien Jarno wrote: Hi alpha porters, I am trying to get eglibc 2.13 ready to get uploaded into unstable. I have done the missing porting work on alpha, but I am now stuck with testsuite regressions, and I would need help to fix them. First of all paer.debian.org, and the machine on the ESIEE cluster I am using is still running a 2.6.22 kernel, which is too old for the minimum kernel version we are targeting for wheezy (2.6.26). I would appreciate if I can get access to a machine running a 2.6.26+ kernel. fyi, paer is running 2.6.26... it hasn't ran anything older for years (though it was running 2.6.32 until the recent reinstall). dannf@paer:~$ uname -a Linux paer 2.6.26-2-parisc64-smp #1 SMP Thu Feb 3 10:23:00 UTC 2011 parisc64 GNU/Linux Thanks, 2.6.26 is find enough. Could you please create a sid chroot on this machine? I've requested this in RT #3081 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110327204045.gs10...@dannf.org
Re: Help needed with eglibc 2.13
On Sat, Mar 19, 2011 at 02:03:00PM +0100, Aurelien Jarno wrote: Hi alpha porters, I am trying to get eglibc 2.13 ready to get uploaded into unstable. I have done the missing porting work on alpha, but I am now stuck with testsuite regressions, and I would need help to fix them. First of all paer.debian.org, and the machine on the ESIEE cluster I am using is still running a 2.6.22 kernel, which is too old for the minimum kernel version we are targeting for wheezy (2.6.26). I would appreciate if I can get access to a machine running a 2.6.26+ kernel. fyi, paer is running 2.6.26... it hasn't ran anything older for years (though it was running 2.6.32 until the recent reinstall). dannf@paer:~$ uname -a Linux paer 2.6.26-2-parisc64-smp #1 SMP Thu Feb 3 10:23:00 UTC 2011 parisc64 GNU/Linux I can upgrade it again to 2.6.32 though, if you like. -dann Here are the regressions I got (when building for a 2.6.22 kernel, so the results might change): - test-double.out, Error 1 - test-float.out, Error 1 - test-idouble.out, Error 1 - test-ifloat.out, Error 1 These ones are due to the new fma() tests which fail on hppa. This is not strictly speaking a regression (I mean strncmp() was already broken in eglibc 2.11), so I can easily ignore this test if the porters agree. - tst-tls9-static.out, Error 1 - tststatic2.out, Error 1 These one looks more problematic, I don't know from where they come. Help will be greatly appreciated. Thanks, Aurelien -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110325194830.gl10...@dannf.org
Bug#577577: O_FSYNC used but not defined on some archs
Package: libc6-dev Version: 2.10.2-6 Severity: important On some archs (hppa and sparc at least), there is no O_FSYNC define in bits/fcntl.h. However, even on these archs, we have this block of defines: #ifdef __USE_BSD # define FAPPENDO_APPEND # define FFSYNC O_FSYNC # define FASYNC O_ASYNC # define FNONBLOCK O_NONBLOCK # define FNDELAYO_NDELAY #endif /* Use BSD. */ This makes code with an #ifdef FFSYNC do the wrong thing, as FFSYNC gets literally defined to the string O_FSYNC. This results in a FTBFS for libexplian, see #559959. (Creating a new bug instead of reassigning because, presumably, that bug could also be worked around in libexplain). -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100412201439.gk13...@ldl.fc.hp.com
Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash
On Mon, Jan 04, 2010 at 05:47:54PM +0200, Modestas Vainius wrote: On pirmadienis 04 Sausis 2010 17:18:40 Helge Deller wrote: libc6-2.10.2-3 made it much, *much* better (I'm not sure yet why!!). But I can still reproduce the bug on my system with your testcases. It's just much harder to reproduce it, but it still happens. So, it's not fixed yet, it just happens much less often. Indeed, you are right. I was able to run `./minifail qt` 90k times without a hang, but it hang at the 3000+th run next time. Anyway, probability of hitting this bug has become much much lower now so maybe KDE will finally build on hppa now. Even if build fails with a timeout like previously, it should be enough to give back it once again. given back. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#434799: FTBFS (hppa): undefined reference to `THREAD_GSCOPE_RESET_FLAG'
Package: glibc Version: 2.6-4 Severity: serious From: http://buildd.debian.org/fetch.cgi?pkg=glibcver=2.6-4arch=hppastamp=1185478685file=log [snip] gcc-4.2 -nostdlib -nostartfiles -shared -o /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/ld.so \ -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs \ /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os -Wl,--version-script=/build/buildd/glibc-2.6/build-tree/hppa-libc/ld.map \ -Wl,-soname=ld.so.1 -T /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/ld.so.lds /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function `_dl_fixup': /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-runtime.c:110: undefined reference to `THREAD_GSCOPE_RESET_FLAG' /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-runtime.c:103: undefined reference to `THREAD_GSCOPE_SET_FLAG' /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function `_dl_profile_fixup': /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-runtime.c:195: undefined reference to `THREAD_GSCOPE_SET_FLAG' /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-runtime.c:203: undefined reference to `THREAD_GSCOPE_RESET_FLAG' /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function `_dl_scope_free': /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:195: undefined reference to `THREAD_GSCOPE_WAIT' /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:181: undefined reference to `THREAD_GSCOPE_WAIT' /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function `add_to_global': /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:162: undefined reference to `atomic_write_barrier' /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:145: undefined reference to `THREAD_GSCOPE_WAIT' /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function `dl_open_worker': /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:478: undefined reference to `atomic_write_barrier' /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function `_dl_close_worker': /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-close.c:499: undefined reference to `THREAD_GSCOPE_WAIT' collect2: ld returned 1 exit status make[3]: *** [/build/buildd/glibc-2.6/build-tree/hppa-libc/elf/ld.so] Error 1 make[3]: Leaving directory `/build/buildd/glibc-2.6/build-tree/glibc-2.6/elf' make[2]: *** [elf/subdir_lib] Error 2 make[2]: Leaving directory `/build/buildd/glibc-2.6/build-tree/glibc-2.6' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/glibc-2.6/build-tree/hppa-libc' make: *** [/build/buildd/glibc-2.6/stamp-dir/build_libc] Error 2 -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402776: still exists in 2.3.6.ds1-10
reopen 402776 found 402776 2.3.6.ds1-10 thanks Reopening, I can still reproduce this on ia64. [EMAIL PROTECTED]:~$ dpkg -l libc6.1 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii libc6.12.3.6.ds1-10 GNU C Library: Shared libraries [EMAIL PROTECTED]:~$ zdump -v America/New_York | head -4 America/New_York -9223372036854775808 = NULL America/New_York -9223372036854689408 = NULL America/New_York Sun Mar 31 06:59:59 1918 UTC = Sun Mar 31 01:59:59 1918 EST isdst=0 gmtoff=-18000 America/New_York Sun Mar 31 07:00:00 1918 UTC = Sun Mar 31 03:00:00 1918 EDT isdst=1 gmtoff=-14400 [EMAIL PROTECTED]:~$ zdump -v America/New_York | tail -4 America/New_York Sun Nov 1 05:59:59 2037 UTC = Sun Nov 1 01:59:59 2037 EDT isdst=1 gmtoff=-14400 America/New_York Sun Nov 1 06:00:00 2037 UTC = Sun Nov 1 01:00:00 2037 EST isdst=0 gmtoff=-18000 America/New_York 9223372036854689407 = NULL America/New_York 9223372036854775807 = NULL -- dann frazier | HP Open Source and Linux Organization -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402776: still exists in 2.3.6.ds1-10
On Thu, Jan 18, 2007 at 07:38:45PM +0100, Aurelien Jarno wrote: Looking more closely to the manpage it seems there is actually no bug, the program behaves as expected: For each zonename on the command line, print the time at the lowest possible time value, the time one day after the lowest possible time value, the times both one second before... So that's normal that the output is different on architectures where time_t has a 64-bit type. -9223372036854775808 and 9223372036854775807 are not really representable in our current gregorian calendar, so those date are displayed as NULL. makes sense. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#276312: fix for #276312
I'm trying to locate a fix for #276312 to backport to sarge's glibc, but I'm having trouble tracking down the actual patch. It looks like it was fixed by grabbing a new upstream. Does someone here perhaps have a pointer? The reporter seemed to think that this is related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108631, but I do not think that's the case - in fact, sarge already has the code that RedHat used to fix that bug (afaict). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.2 from the archive?
On Fri, May 26, 2006 at 03:29:49PM +0200, Andreas Barth wrote: * dann frazier ([EMAIL PROTECTED]) [060526 15:14]: On Mon, May 22, 2006 at 01:24:52PM +0200, Sven Luther wrote: On Sun, May 21, 2006 at 11:20:38PM +0200, Christian T. Steigies wrote: need some further discussion among the m68k folks... does this also mean that an etch installation will require a 2.6 kernel to run on the machine? Some of the m68k buildds (most macs) are still running 2.2.25, the two Atari Falcons run 2.4. The long term aim is indeed to release etch with only 2.6 kernels, which means no 2.4 but also no 2.2 kernel. Now, the removal of the 2.2 kernel should follow the same roadmap as what was discussed for the 2.4 kernels, and i suppose that for m68k purpose, you can substitute '2.4' with '2.2 or 2.4' in all those emails. There has been no DSA for a 2.2 kernel to date in the lifetime of woody/sarge (counting on my recollection here, I'm currently offline), so I can't see how we can continue shipping it unless someone steps up to handle this. Of course, you could always request insecure status from the release team (with proper release notes, etc). As far as I know, 2.2 isn't even supported by glibc any more. I've cc'd the glibc list for confirmation. If that is the case, we definitly shouldn't ship with 2.2. Also, anyone is free to open a kernel-2-2.debian.net repository kernel.debian.net has a repository that could be used for stuff like this. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320240: raising severity
severity 320240 grave thanks Raising the severity because this is generating a ton of FTBFS issues - pretty much anything w/ C++. I'm told this is fixed in experimental; if someone can confirm, please tag as such. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292673: works for me
GOTO, Your debs worked for me - evolution now starts w/o LD_ASSUME_KERNEL=2.4.18. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292673: why was the sarge tag removed?
On Fri, 2005-02-25 at 10:56 +0100, Frank Lichtenheld wrote: On Thu, Feb 24, 2005 at 02:53:43PM -0700, dann frazier wrote: Why was the sarge tag removed? Did I misuse it? Probably. The sarge tag is for bugs that only appear in testing but not in unstable. Since I couldn't see anything in your report that was specific to sarge I removed the tag. This issue is in sarge and sid, thanks for fixing it. -- dann frazier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292673: why was the sarge tag removed?
Why was the sarge tag removed? Did I misuse it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292673: NPTL vs. LinuxThread sizeof(struct pthread) conflict causes memory corruption
Package: glibc Severity: grave Tags: sarge On Fri, 2005-01-28 at 09:48 -0800, David Mosberger wrote: Hi Dann, I don't seem to be getting much traction in getting the NPTL ld.so bug resolved. I posted a glibc bug-report: http://sources.redhat.com/bugzilla/show_bug.cgi?id=685 Including report inline here Several of us noticed that evolution on Debian/unstable sometimes crashes early during program startup. It turns out that the crash is due to memory corruption. In one particular case, the memory that got corrupted was in the address range: 0x22daff10-0x22daff1f which happened to hold the function descriptors for shared library linkage stubs (jump slots). Of relevance was that the thread-pointer (r13) had the value: 0x22db0500 The corruption was caused by any NPTL routine trying to access the thread-descriptor, since NPTL uses a struct pthread of size 1680 bytes (0x690). I believe the problem is due to the fact that /lib/ld-linux-ia64.so.2 was built for Linux Threads, which uses a thread descriptor size of 0x500. Note that sysdeps/generic/dl-tls.c has several references to TLS_PRE_TCB_SIZE for the case where TLS_DTV_AT_TP is defined. In other words, ld.so ends up having a dependency on the size of the thread-descriptor. Sure enough, if I invoke evolution like this: /lib/tls/ld-linux-ia64.so.2 evolution it works just fine. My understanding is that /lib/ld-linux-ia64.so.2 should work for both NPTL and LinuxThreads libraries and the dependency on the size of the thread-descriptor is accidental. I believe this same bug may affect Alpha, PowerPC, and SH. For Alpha, I found this bug report, which sounds potentially related: http://sources.redhat.com/bugzilla/show_bug.cgi?id=299 and sent a mail to libc-hacker: http://sources.redhat.com/ml/libc-hacker/2005-01/msg00071.html and there has been no response whatsoever so far. I'm not sure what the original authors had in mind here, so I'm not sure what the proper way is to fix this problem. A stop-gap solution might be to just do: # mv /lib/tls/ld-2.3.2.so /lib/ I did this on my Debian/unstable system and it seems to work just fine. I did verify beforehand that the two versions of ld-2.3.2 do export the exact same set of symbols, so this ought to be fairly safe. It works around the bug since the NPTL value of TLS_PRE_TCB_SIZE is bigger than that for LinuxThreads. Perhaps this should be the recommended workaround for Debian for the time being? I'm CC'ing Al Stone - maybe he has a suggestion with how to interact w/ glibc upstream, or what the proper fix may be. I'm filing this bug as release critical, given it causes memory corruption on potentially 4 architectures. If the glibc maintainers disagree, I'm sure they'll downgrade. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#223460: [dannf@debian.org: reopening]
Package: linux-kernel-headers Version: 2.5.999-test7-bk-9 Severity: important oops - tried to reopen an archived bug. opening a new one instead. see #218645 for the original report. - Forwarded message from dann frazier [EMAIL PROTECTED] - From: dann frazier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: reopening this bug exists in unstable - dunno if its a regression or if it wasn't fixed the first time. ... gcc -O2 -Wall -I../../../util/../include -D_GNU_SOURCE -DCONFIG_ROOT_CHECK_OFF=0 -DELF_MACHINE_H='elf_ia64.h' -DARCH_ia64 -c -o arch64.o ../../../util/arch64.c In file included from ../../../util/arch64.c:24: ../../../include/util.h:42: warning: built-in function `log' declared as non-function gcc -O2 -Wall -I../../../util/../include -D_GNU_SOURCE -DCONFIG_ROOT_CHECK_OFF=0 -DELF_MACHINE_H='elf_ia64.h' -DARCH_ia64 -c -o gzfiles.o ../../../util/gzfiles.c gcc -O2 -Wall -I../../../util/../include -D_GNU_SOURCE -DCONFIG_ROOT_CHECK_OFF=0 -DELF_MACHINE_H='elf_ia64.h' -DARCH_ia64 -c -o sys_nim.o ../../../util/sys_nim.c gcc -O2 -Wall -I../../../util/../include -D_GNU_SOURCE -DCONFIG_ROOT_CHECK_OFF=0 -DELF_MACHINE_H='elf_ia64.h' -DARCH_ia64 -c -o sys_oim.o ../../../util/sys_oim.c ../../../util/sys_oim.c:36: error: parse error before old_sys_init_module make[2]: *** [sys_oim.o] Error 1 make[2]: Leaving directory `/tmp/modutils-2.4.25/debian/build/util' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/modutils-2.4.25/debian/build' make: *** [stamp-build] Error 2 [EMAIL PROTECTED]:/tmp/modutils-2.4.25$ COLUMNS=100 dpkg -l | grep libc6.1 ii libc6.1 2.3.2.ds1-10.0.1GNU C Library: Shared libraries and Timezone data ii libc6.1-dbg 2.3.2.ds1-10.0.1GNU C Library: Libraries with debugging symbols ii libc6.1-dev 2.3.2.ds1-10.0.1GNU C Library: Development Libraries and Header Files [EMAIL PROTECTED]:/tmp/modutils-2.4.25$ COLUMNS=100 dpkg -l linux-kernel-headers Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersion Description +++-===-===-== ii linux-kernel-header 2.5.999-test7-bk-9 Linux Kernel Headers for development - End forwarded message -
Bug#223460: [dannf@debian.org: reopening]
Package: linux-kernel-headers Version: 2.5.999-test7-bk-9 Severity: important oops - tried to reopen an archived bug. opening a new one instead. see #218645 for the original report. - Forwarded message from dann frazier [EMAIL PROTECTED] - From: dann frazier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: reopening this bug exists in unstable - dunno if its a regression or if it wasn't fixed the first time. ... gcc -O2 -Wall -I../../../util/../include -D_GNU_SOURCE -DCONFIG_ROOT_CHECK_OFF=0 -DELF_MACHINE_H='elf_ia64.h' -DARCH_ia64 -c -o arch64.o ../../../util/arch64.c In file included from ../../../util/arch64.c:24: ../../../include/util.h:42: warning: built-in function `log' declared as non-function gcc -O2 -Wall -I../../../util/../include -D_GNU_SOURCE -DCONFIG_ROOT_CHECK_OFF=0 -DELF_MACHINE_H='elf_ia64.h' -DARCH_ia64 -c -o gzfiles.o ../../../util/gzfiles.c gcc -O2 -Wall -I../../../util/../include -D_GNU_SOURCE -DCONFIG_ROOT_CHECK_OFF=0 -DELF_MACHINE_H='elf_ia64.h' -DARCH_ia64 -c -o sys_nim.o ../../../util/sys_nim.c gcc -O2 -Wall -I../../../util/../include -D_GNU_SOURCE -DCONFIG_ROOT_CHECK_OFF=0 -DELF_MACHINE_H='elf_ia64.h' -DARCH_ia64 -c -o sys_oim.o ../../../util/sys_oim.c ../../../util/sys_oim.c:36: error: parse error before old_sys_init_module make[2]: *** [sys_oim.o] Error 1 make[2]: Leaving directory `/tmp/modutils-2.4.25/debian/build/util' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/modutils-2.4.25/debian/build' make: *** [stamp-build] Error 2 [EMAIL PROTECTED]:/tmp/modutils-2.4.25$ COLUMNS=100 dpkg -l | grep libc6.1 ii libc6.1 2.3.2.ds1-10.0.1GNU C Library: Shared libraries and Timezone data ii libc6.1-dbg 2.3.2.ds1-10.0.1GNU C Library: Libraries with debugging symbols ii libc6.1-dev 2.3.2.ds1-10.0.1GNU C Library: Development Libraries and Header Files [EMAIL PROTECTED]:/tmp/modutils-2.4.25$ COLUMNS=100 dpkg -l linux-kernel-headers Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersion Description +++-===-===-== ii linux-kernel-header 2.5.999-test7-bk-9 Linux Kernel Headers for development - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#220331: linux-kernel-headers: parse error in buffer_head.h
Package: linux-kernel-headers Version: 2.5.999-test7-bk-9 Severity: important snippet from my log - you can reproduce by trying to build dosfstools on ia64. I tested this specifically to look for regressions, because I recall this being broken fixed at one point (can't find the bug report at the moment though). dpkg-source: building dosfstools in dosfstools_2.10-1.dsc debian/rules build make DEBUGFLAGS=-g OPTFLAGS=-O2 -fomit-frame-pointer make[1]: Entering directory `/tmp/dosfstools-2.10' make -C mkdosfs all make[2]: Entering directory `/tmp/dosfstools-2.10/mkdosfs' gcc -O2 -fomit-frame-pointer -Wall -g -c mkdosfs.c -o mkdosfs.o In file included from /usr/include/linux/fs.h:16, from mkdosfs.c:54: /usr/include/linux/list.h:576:2: warning: #warning don't include kernel headers in userspace gcc mkdosfs.o -o mkdosfs make[2]: Leaving directory `/tmp/dosfstools-2.10/mkdosfs' make -C dosfsck all make[2]: Entering directory `/tmp/dosfstools-2.10/dosfsck' gcc -c -O2 -fomit-frame-pointer -Wall -g boot.c In file included from /usr/include/linux/msdos_fs.h:7, from dosfsck.h:16, from boot.c:13: /usr/include/linux/buffer_head.h:54: error: parse error before sector_t /usr/include/linux/buffer_head.h:62: error: parse error before '}' token /usr/include/linux/buffer_head.h: In function `set_buffer_uptodate': /usr/include/linux/buffer_head.h:107: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `clear_buffer_uptodate': /usr/include/linux/buffer_head.h:107: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `buffer_uptodate': /usr/include/linux/buffer_head.h:107: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `set_buffer_dirty': /usr/include/linux/buffer_head.h:108: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `clear_buffer_dirty': /usr/include/linux/buffer_head.h:108: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `buffer_dirty': /usr/include/linux/buffer_head.h:108: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `test_set_buffer_dirty': /usr/include/linux/buffer_head.h:109: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `test_clear_buffer_dirty': /usr/include/linux/buffer_head.h:109: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `set_buffer_locked': /usr/include/linux/buffer_head.h:110: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `clear_buffer_locked': /usr/include/linux/buffer_head.h:110: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `buffer_locked': /usr/include/linux/buffer_head.h:110: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `test_set_buffer_locked': /usr/include/linux/buffer_head.h:111: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `test_clear_buffer_locked': /usr/include/linux/buffer_head.h:111: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `set_buffer_req': /usr/include/linux/buffer_head.h:112: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `clear_buffer_req': /usr/include/linux/buffer_head.h:112: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `buffer_req': /usr/include/linux/buffer_head.h:112: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `test_set_buffer_req': /usr/include/linux/buffer_head.h:113: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `test_clear_buffer_req': /usr/include/linux/buffer_head.h:113: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `set_buffer_mapped': /usr/include/linux/buffer_head.h:114: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `clear_buffer_mapped': /usr/include/linux/buffer_head.h:114: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `buffer_mapped': /usr/include/linux/buffer_head.h:114: error: dereferencing pointer to incomplete type -- System Information: Debian Release: testing/unstable Architecture: ia64 Kernel: Linux krebs 2.4.20-mckinley #1 Thu Sep 11 18:27:20 MDT 2003 ia64 Locale: LANG=C, LC_CTYPE=C -- no debconf information
Bug#220331: linux-kernel-headers: parse error in buffer_head.h
Package: linux-kernel-headers Version: 2.5.999-test7-bk-9 Severity: important snippet from my log - you can reproduce by trying to build dosfstools on ia64. I tested this specifically to look for regressions, because I recall this being broken fixed at one point (can't find the bug report at the moment though). dpkg-source: building dosfstools in dosfstools_2.10-1.dsc debian/rules build make DEBUGFLAGS=-g OPTFLAGS=-O2 -fomit-frame-pointer make[1]: Entering directory `/tmp/dosfstools-2.10' make -C mkdosfs all make[2]: Entering directory `/tmp/dosfstools-2.10/mkdosfs' gcc -O2 -fomit-frame-pointer -Wall -g -c mkdosfs.c -o mkdosfs.o In file included from /usr/include/linux/fs.h:16, from mkdosfs.c:54: /usr/include/linux/list.h:576:2: warning: #warning don't include kernel headers in userspace gcc mkdosfs.o -o mkdosfs make[2]: Leaving directory `/tmp/dosfstools-2.10/mkdosfs' make -C dosfsck all make[2]: Entering directory `/tmp/dosfstools-2.10/dosfsck' gcc -c -O2 -fomit-frame-pointer -Wall -g boot.c In file included from /usr/include/linux/msdos_fs.h:7, from dosfsck.h:16, from boot.c:13: /usr/include/linux/buffer_head.h:54: error: parse error before sector_t /usr/include/linux/buffer_head.h:62: error: parse error before '}' token /usr/include/linux/buffer_head.h: In function `set_buffer_uptodate': /usr/include/linux/buffer_head.h:107: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `clear_buffer_uptodate': /usr/include/linux/buffer_head.h:107: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `buffer_uptodate': /usr/include/linux/buffer_head.h:107: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `set_buffer_dirty': /usr/include/linux/buffer_head.h:108: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `clear_buffer_dirty': /usr/include/linux/buffer_head.h:108: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `buffer_dirty': /usr/include/linux/buffer_head.h:108: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `test_set_buffer_dirty': /usr/include/linux/buffer_head.h:109: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `test_clear_buffer_dirty': /usr/include/linux/buffer_head.h:109: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `set_buffer_locked': /usr/include/linux/buffer_head.h:110: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `clear_buffer_locked': /usr/include/linux/buffer_head.h:110: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `buffer_locked': /usr/include/linux/buffer_head.h:110: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `test_set_buffer_locked': /usr/include/linux/buffer_head.h:111: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `test_clear_buffer_locked': /usr/include/linux/buffer_head.h:111: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `set_buffer_req': /usr/include/linux/buffer_head.h:112: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `clear_buffer_req': /usr/include/linux/buffer_head.h:112: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `buffer_req': /usr/include/linux/buffer_head.h:112: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `test_set_buffer_req': /usr/include/linux/buffer_head.h:113: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `test_clear_buffer_req': /usr/include/linux/buffer_head.h:113: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `set_buffer_mapped': /usr/include/linux/buffer_head.h:114: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `clear_buffer_mapped': /usr/include/linux/buffer_head.h:114: error: dereferencing pointer to incomplete type /usr/include/linux/buffer_head.h: In function `buffer_mapped': /usr/include/linux/buffer_head.h:114: error: dereferencing pointer to incomplete type -- System Information: Debian Release: testing/unstable Architecture: ia64 Kernel: Linux krebs 2.4.20-mckinley #1 Thu Sep 11 18:27:20 MDT 2003 ia64 Locale: LANG=C, LC_CTYPE=C -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#220138: linux-kernel-headers: pal.h header busted again
Package: linux-kernel-headers Version: 2.5.999-test7-bk-9 Severity: important I tried to build discover today noticed the pal.h bug is back again. This used to be worked around in the kernel-headers package with this patch: --- linux/include/asm-ia64/pal.h2002-07-11 12:06:59.0 -0600 +++ /usr/include/asm/pal.h 2002-08-28 21:48:00.0 -0600 @@ -1,6 +1,8 @@ #ifndef _ASM_IA64_PAL_H #define _ASM_IA64_PAL_H +#ifdef __KERNEL__ + /* * Processor Abstraction Layer definitions. * @@ -1402,4 +1404,6 @@ #endif /* __ASSEMBLY__ */ +#endif /* __KERNEL__ */ + #endif /* _ASM_IA64_PAL_H */ discover build failure: mkdir .libs gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I.. -g -O2 -Wall -Wp,-MD,.deps/bridge.pp -c bridge.c -fPIC -DPIC -o .libs/bridge.lo In file included from /usr/include/linux/device.h:17, from /usr/include/linux/genhd.h:15, from discover.h:25, from bridge.c:22: /usr/include/linux/list.h:576:2: warning: #warning don't include kernel headers in userspace In file included from /usr/include/asm/system.h:19, from /usr/include/linux/spinlock.h:17, from /usr/include/linux/device.h:18, from /usr/include/linux/genhd.h:15, from discover.h:25, from bridge.c:22: /usr/include/asm/pal.h:89: error: parse error before pal_status_t /usr/include/asm/pal.h:102: error: parse error before pal_cache_level_t /usr/include/asm/pal.h:110: error: parse error before pal_cache_type_t /usr/include/asm/pal.h:123: error: parse error before pal_cache_line_state_t /usr/include/asm/pal.h:130: error: parse error before u64 /usr/include/asm/pal.h:135: error: parse error before u64 /usr/include/asm/pal.h:146: error: parse error before pcci1_data /usr/include/asm/pal.h:151: error: parse error before u64 /usr/include/asm/pal.h:162: error: parse error before pcci2_data /usr/include/asm/pal.h:167: error: parse error before pal_status_t /usr/include/asm/pal.h:169: error: parse error before pcci_info_2 /usr/include/asm/pal.h:170: error: parse error before pcci_reserved /usr/include/asm/pal.h:207: error: parse error before u32 ... -- System Information: Debian Release: testing/unstable Architecture: ia64 Kernel: Linux krebs 2.4.20-mckinley #1 Thu Sep 11 18:27:20 MDT 2003 ia64 Locale: LANG=C, LC_CTYPE=C -- no debconf information
Bug#220138: linux-kernel-headers: pal.h header busted again
Package: linux-kernel-headers Version: 2.5.999-test7-bk-9 Severity: important I tried to build discover today noticed the pal.h bug is back again. This used to be worked around in the kernel-headers package with this patch: --- linux/include/asm-ia64/pal.h2002-07-11 12:06:59.0 -0600 +++ /usr/include/asm/pal.h 2002-08-28 21:48:00.0 -0600 @@ -1,6 +1,8 @@ #ifndef _ASM_IA64_PAL_H #define _ASM_IA64_PAL_H +#ifdef __KERNEL__ + /* * Processor Abstraction Layer definitions. * @@ -1402,4 +1404,6 @@ #endif /* __ASSEMBLY__ */ +#endif /* __KERNEL__ */ + #endif /* _ASM_IA64_PAL_H */ discover build failure: mkdir .libs gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I.. -g -O2 -Wall -Wp,-MD,.deps/bridge.pp -c bridge.c -fPIC -DPIC -o .libs/bridge.lo In file included from /usr/include/linux/device.h:17, from /usr/include/linux/genhd.h:15, from discover.h:25, from bridge.c:22: /usr/include/linux/list.h:576:2: warning: #warning don't include kernel headers in userspace In file included from /usr/include/asm/system.h:19, from /usr/include/linux/spinlock.h:17, from /usr/include/linux/device.h:18, from /usr/include/linux/genhd.h:15, from discover.h:25, from bridge.c:22: /usr/include/asm/pal.h:89: error: parse error before pal_status_t /usr/include/asm/pal.h:102: error: parse error before pal_cache_level_t /usr/include/asm/pal.h:110: error: parse error before pal_cache_type_t /usr/include/asm/pal.h:123: error: parse error before pal_cache_line_state_t /usr/include/asm/pal.h:130: error: parse error before u64 /usr/include/asm/pal.h:135: error: parse error before u64 /usr/include/asm/pal.h:146: error: parse error before pcci1_data /usr/include/asm/pal.h:151: error: parse error before u64 /usr/include/asm/pal.h:162: error: parse error before pcci2_data /usr/include/asm/pal.h:167: error: parse error before pal_status_t /usr/include/asm/pal.h:169: error: parse error before pcci_info_2 /usr/include/asm/pal.h:170: error: parse error before pcci_reserved /usr/include/asm/pal.h:207: error: parse error before u32 ... -- System Information: Debian Release: testing/unstable Architecture: ia64 Kernel: Linux krebs 2.4.20-mckinley #1 Thu Sep 11 18:27:20 MDT 2003 ia64 Locale: LANG=C, LC_CTYPE=C -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#186331: raising severity; was: busybox FTBTS problems
On Sun, Aug 03, 2003 at 10:44:23AM +0100, Alastair McKinstry wrote: The adjtimex bug has been assigned to libc6 already, with a note that its now severity serious as it breaks d-i. I'm proposing to do binary NMUs for alpha, ia64 busybox-cvs : hence I'm CC'ing all the uploaders for busybox CVS (its maintainer is set to debian-boot). Any objections? getting ia64 building needs more than just a rebuild against the newer libc6.1-dev - it needs source changes too. see #201161.
Bug#186654: FW: IMPORTANT bug fix for setjmp()/getcontext()
Package: libc6.1 Version: 2.3.1-16 - Forwarded message from David Mosberger [EMAIL PROTECTED] - Content-Description: forwarded message Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Archive: http://sources.redhat.com/ml/libc-hacker/ List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED], http://sources.redhat.com/ml/#faqs X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.3, required 7, PATCH_UNIFIED_DIFF) From: David Mosberger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: ia64: unat restoration fixes for setjmp() getcontext() Reply-To: [EMAIL PROTECTED] The ia64 versions of __sigsetjmp() and getcontext() failed to restore ar.unat before returning. Patch below should fix that. --david 2003-03-27 David Mosberger [EMAIL PROTECTED] * sysdeps/unix/sysv/linux/ia64/getcontext.S: Restore caller's ar.unat before returning. Add missing .mem.offset directives to ensure file gets assembled without warnings. * sysdeps/unix/sysv/linux/ia64/setjmp.S: Ditto. Index: sysdeps/unix/sysv/linux/ia64/setjmp.S === RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/ia64/setjmp.S,v retrieving revision 1.7 diff -u -r1.7 setjmp.S --- sysdeps/unix/sysv/linux/ia64/setjmp.S 31 Dec 2002 20:37:30 - 1.7 +++ sysdeps/unix/sysv/linux/ia64/setjmp.S 27 Mar 2003 18:05:14 - @@ -87,21 +87,22 @@ ENTRY(__sigsetjmp) .prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(2) alloc loc1=ar.pfs,2,2,2,0 + .save ar.unat, r16 mov r16=ar.unat ;; mov r17=ar.fpsr mov r2=in0 add r3=8,in0 ;; - st8.spill.nta [r2]=sp,16// r12 (sp) - st8.spill.nta [r3]=gp,16// r1 (gp) +.mem.offset 8,0; st8.spill.nta [r2]=sp,16// r12 (sp) +.mem.offset 0,0; st8.spill.nta [r3]=gp,16// r1 (gp) ;; st8.nta [r2]=r16,16 // save caller's unat st8.nta [r3]=r17,16 // save fpsr add r8=0xa0,in0 ;; - st8.spill.nta [r2]=r4,16// r4 - st8.spill.nta [r3]=r5,16// r5 +.mem.offset 8,0; st8.spill.nta [r2]=r4,16// r4 +.mem.offset 0,0; st8.spill.nta [r3]=r5,16// r5 add r9=0xb0,in0 ;; stf.spill.nta [r8]=f2,32 @@ -143,8 +144,8 @@ stf.spill.nta [r8]=f30 stf.spill.nta [r9]=f31 - st8.spill.nta [r2]=r6,16// r6 - st8.spill.nta [r3]=r7,16// r7 +.mem.offset 8,0; st8.spill.nta [r2]=r6,16// r6 +.mem.offset 0,0; st8.spill.nta [r3]=r7,16// r7 ;; mov r23=ar.bsp mov r25=ar.unat @@ -170,9 +171,10 @@ st8.nta [r3]=in0// __jmp_buf br.call.dpnt.few rp=__sigjmp_save .ret0: // force a new bundle ::q - mov r8=0 + mov.m ar.unat=r16 // restore caller's unat mov rp=loc0 mov ar.pfs=loc1 + mov r8=0 ret END(__sigsetjmp) Index: sysdeps/unix/sysv/linux/ia64/getcontext.S === RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/ia64/getcontext.S,v retrieving revision 1.6 diff -u -r1.6 getcontext.S --- sysdeps/unix/sysv/linux/ia64/getcontext.S 9 Oct 2002 09:57:46 - 1.6 +++ sysdeps/unix/sysv/linux/ia64/getcontext.S 27 Mar 2003 19:33:04 - @@ -34,6 +34,7 @@ other than the PRESERVED state. */ ENTRY(__getcontext) + .prologue alloc r16 = ar.pfs, 1, 0, 3, 0 // sigprocmask (SIG_BLOCK, NULL, sc-sc_mask): @@ -53,7 +54,9 @@ add r2 = SC_GR+1*8, r32 ;; mov.m rBSP = ar.bsp + .save ar.unat, rUNAT mov.m rUNAT = ar.unat + .body add r3 = SC_GR+4*8, r32 ;; @@ -65,8 +68,8 @@ .mem.offset 8,0; st8.spill [r3] = r6, 48 and rTMP = ~0x3, rRSC ;; - st8.spill [r2] = r7, (SC_FR+2*16-(SC_GR+7*8)) - st8.spill [r3] = sp, (SC_FR+3*16-(SC_GR+12*8)) +.mem.offset 0,0; st8.spill [r2] = r7, (SC_FR+2*16-(SC_GR+7*8)) +.mem.offset 8,0; st8.spill [r3] = sp, (SC_FR+3*16-(SC_GR+12*8)) ;; mov.m ar.rsc = rTMP // put RSE into enforced lazy mode mov.m rNAT = ar.unat @@ -119,8 +122,8 @@ stf.spill [r3] = f31, 32 mov rB1 = b1 ;; + mov ar.unat = rUNAT // we're done spilling integer regs; restore caller's UNaT add r2 = SC_NAT, r32 - nop 0 add r3 = SC_BSP, r32 ;; st8 [r2] = rNAT, (SC_RNAT-SC_NAT) - End forwarded message - -- --- dann frazier Hewlett-Packard Linux Systems Division [EMAIL PROTECTED] (970) 898-0800 -- To UNSUBSCRIBE, email to [EMAIL
Bug#186654: FW: IMPORTANT bug fix for setjmp()/getcontext()
Package: libc6.1 Version: 2.3.1-16 - Forwarded message from David Mosberger [EMAIL PROTECTED] - Content-Description: forwarded message Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Archive: http://sources.redhat.com/ml/libc-hacker/ List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED], http://sources.redhat.com/ml/#faqs X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.3, required 7, PATCH_UNIFIED_DIFF) From: David Mosberger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: ia64: unat restoration fixes for setjmp() getcontext() Reply-To: [EMAIL PROTECTED] The ia64 versions of __sigsetjmp() and getcontext() failed to restore ar.unat before returning. Patch below should fix that. --david 2003-03-27 David Mosberger [EMAIL PROTECTED] * sysdeps/unix/sysv/linux/ia64/getcontext.S: Restore caller's ar.unat before returning. Add missing .mem.offset directives to ensure file gets assembled without warnings. * sysdeps/unix/sysv/linux/ia64/setjmp.S: Ditto. Index: sysdeps/unix/sysv/linux/ia64/setjmp.S === RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/ia64/setjmp.S,v retrieving revision 1.7 diff -u -r1.7 setjmp.S --- sysdeps/unix/sysv/linux/ia64/setjmp.S 31 Dec 2002 20:37:30 - 1.7 +++ sysdeps/unix/sysv/linux/ia64/setjmp.S 27 Mar 2003 18:05:14 - @@ -87,21 +87,22 @@ ENTRY(__sigsetjmp) .prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(2) alloc loc1=ar.pfs,2,2,2,0 + .save ar.unat, r16 mov r16=ar.unat ;; mov r17=ar.fpsr mov r2=in0 add r3=8,in0 ;; - st8.spill.nta [r2]=sp,16// r12 (sp) - st8.spill.nta [r3]=gp,16// r1 (gp) +.mem.offset 8,0; st8.spill.nta [r2]=sp,16// r12 (sp) +.mem.offset 0,0; st8.spill.nta [r3]=gp,16// r1 (gp) ;; st8.nta [r2]=r16,16 // save caller's unat st8.nta [r3]=r17,16 // save fpsr add r8=0xa0,in0 ;; - st8.spill.nta [r2]=r4,16// r4 - st8.spill.nta [r3]=r5,16// r5 +.mem.offset 8,0; st8.spill.nta [r2]=r4,16// r4 +.mem.offset 0,0; st8.spill.nta [r3]=r5,16// r5 add r9=0xb0,in0 ;; stf.spill.nta [r8]=f2,32 @@ -143,8 +144,8 @@ stf.spill.nta [r8]=f30 stf.spill.nta [r9]=f31 - st8.spill.nta [r2]=r6,16// r6 - st8.spill.nta [r3]=r7,16// r7 +.mem.offset 8,0; st8.spill.nta [r2]=r6,16// r6 +.mem.offset 0,0; st8.spill.nta [r3]=r7,16// r7 ;; mov r23=ar.bsp mov r25=ar.unat @@ -170,9 +171,10 @@ st8.nta [r3]=in0// __jmp_buf br.call.dpnt.few rp=__sigjmp_save .ret0: // force a new bundle ::q - mov r8=0 + mov.m ar.unat=r16 // restore caller's unat mov rp=loc0 mov ar.pfs=loc1 + mov r8=0 ret END(__sigsetjmp) Index: sysdeps/unix/sysv/linux/ia64/getcontext.S === RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/ia64/getcontext.S,v retrieving revision 1.6 diff -u -r1.6 getcontext.S --- sysdeps/unix/sysv/linux/ia64/getcontext.S 9 Oct 2002 09:57:46 - 1.6 +++ sysdeps/unix/sysv/linux/ia64/getcontext.S 27 Mar 2003 19:33:04 - @@ -34,6 +34,7 @@ other than the PRESERVED state. */ ENTRY(__getcontext) + .prologue alloc r16 = ar.pfs, 1, 0, 3, 0 // sigprocmask (SIG_BLOCK, NULL, sc-sc_mask): @@ -53,7 +54,9 @@ add r2 = SC_GR+1*8, r32 ;; mov.m rBSP = ar.bsp + .save ar.unat, rUNAT mov.m rUNAT = ar.unat + .body add r3 = SC_GR+4*8, r32 ;; @@ -65,8 +68,8 @@ .mem.offset 8,0; st8.spill [r3] = r6, 48 and rTMP = ~0x3, rRSC ;; - st8.spill [r2] = r7, (SC_FR+2*16-(SC_GR+7*8)) - st8.spill [r3] = sp, (SC_FR+3*16-(SC_GR+12*8)) +.mem.offset 0,0; st8.spill [r2] = r7, (SC_FR+2*16-(SC_GR+7*8)) +.mem.offset 8,0; st8.spill [r3] = sp, (SC_FR+3*16-(SC_GR+12*8)) ;; mov.m ar.rsc = rTMP // put RSE into enforced lazy mode mov.m rNAT = ar.unat @@ -119,8 +122,8 @@ stf.spill [r3] = f31, 32 mov rB1 = b1 ;; + mov ar.unat = rUNAT // we're done spilling integer regs; restore caller's UNaT add r2 = SC_NAT, r32 - nop 0 add r3 = SC_BSP, r32 ;; st8 [r2] = rNAT, (SC_RNAT-SC_NAT) - End forwarded message - -- --- dann frazier Hewlett-Packard Linux Systems Division [EMAIL PROTECTED] (970) 898-0800
Bug#175928: libc6: dns broken w/ socksify ssh
Package: libc6 Version: 2.3.1-9 Severity: normal ## ssh via socks is unable to resolve my hostname dannf@hazel:~$ socksify ssh home.dannf.org ssh: home.dannf.org: Name or service not known ## but the system can dannf@hazel:~$ host home.dannf.org home.dannf.org A 12.252.80.98 ## and telnet can, under socks dannf@hazel:~$ socksify telnet home.dannf.org 22 Trying 12.252.80.98... Connected to 12-252-80-98.client.attbi.com. Escape character is '^]'. ## and i can socksify ssh if i specify the IP dannf@hazel:~$ socksify ssh 12.252.80.98 Linux home 2.4.18sparc #1 Sun Sep 15 22:31:51 MDT 2002 sparc unknown Most of the programs included with the Debian GNU/Linux system are ... dannf@home:~$ I'm using ssh 3.5p1-3. I tried reverting to 3.4p1, but still had the same issue. I'm using dante-client 1.1.13-1. This also exists on ia64, fwiw. So, as I see it, this could just as likely be a bug in either ssh, libc6 libc6.1, or dante-client, so please reassign as necessary. I've verified that this problem exists on 4 different i386 boxes running sid. However, there is a fifth i386 box running the same versions of these packages that works just fine. woody machines pointing at the same dns/socks servers work fine. On one of the 4 that show this problem, adding an entry for the target host to /etc/hosts fixed the problem. (I couldn't check the other 3). Removing the entry broke it again. This, and the fact that I first noticed the problem after a recent libc6 upgrade, is why I chose to file the bug against libc6. ## my nsswitch.conf is pristine dannf@hazel:~$ grep ^hosts /etc/nsswitch.conf hosts: files dns I tried rebuilding both dante-client and ssh against the headers on the system, but didn't see a change. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux hazel 2.4.19-686-smp #1 SMP Tue Nov 19 00:58:50 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
