Watson to add --keep-existing option to
+locale-gen. (Closes: #298913)
+ * Also restart exim4 on upgrade. (Closes: #326554)
+ * debian/debhelper.in/libc.preinst: Clarify wording of message about
+detection of services needing to be stopped before upgrade.
+
+ -- Philip Blundell [EMAIL
Author: pb
Date: 2005-12-29 13:05:26 + (Thu, 29 Dec 2005)
New Revision: 1083
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/debhelper.in/libc.postinst
glibc-package/trunk/debian/local/manpages/locale-gen.8.sgml
Author: pb
Date: 2005-12-28 12:02:51 + (Wed, 28 Dec 2005)
New Revision: 1074
Added:
glibc-package/trunk/debian/local/manpages/po4a.cfg
glibc-package/trunk/debian/local/manpages/validlocale.8
glibc-package/trunk/debian/local/usr_sbin/validlocale
Modified:
Author: pb
Date: 2005-12-28 12:04:13 + (Wed, 28 Dec 2005)
New Revision: 1075
Added:
glibc-package/trunk/debian/local/manpages/es/
glibc-package/trunk/debian/local/manpages/es/addendum.es
glibc-package/trunk/debian/local/manpages/es/validlocale.es.8
Maintainers debian-glibc@lists.debian.org
Uploaders: Ben Collins [EMAIL PROTECTED], GOTO Masanori [EMAIL PROTECTED],
Philip Blundell [EMAIL PROTECTED], Jeff Bailey [EMAIL PROTECTED], Daniel
Jacobowitz [EMAIL PROTECTED], Clint Adams [EMAIL PROTECTED]
Standards-Version: 3.6.2
@@ -25,8 +25,8
Author: pb
Date: 2005-12-28 20:01:25 + (Wed, 28 Dec 2005)
New Revision: 1080
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/sysdeps/hppa.mk
Log:
* sysdeps/hppa.mk: Add new /usr/hppa64-linux-gnu/include symlink, per
request of Matthias Klose. (Closes:
Author: pb
Date: 2005-12-28 23:47:05 + (Wed, 28 Dec 2005)
New Revision: 1082
Removed:
glibc-package/trunk/debian/local/manpages/fr/termwrap.add
Log:
delete obsolete file
Deleted: glibc-package/trunk/debian/local/manpages/fr/termwrap.add
Author: pb
Date: 2005-12-27 11:38:34 + (Tue, 27 Dec 2005)
New Revision: 1071
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/debhelper.in/libc.postinst
Log:
also restart atd on upgrade
Modified: glibc-package/trunk/debian/changelog
[EMAIL PROTECTED], GOTO Masanori [EMAIL PROTECTED],
Philip Blundell [EMAIL PROTECTED], Jeff Bailey [EMAIL PROTECTED], Daniel
Jacobowitz [EMAIL PROTECTED], Clint Adams [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Author: pb
Date: 2005-12-27 14:07:41 + (Tue, 27 Dec 2005)
New Revision: 1073
Added:
glibc-package/trunk/debian/patches/ctan.dpatch
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/patches/00list
Log:
add patch for ctan bug 328504
Modified:
Author: pb
Date: 2005-12-26 11:57:46 + (Mon, 26 Dec 2005)
New Revision: 1070
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/script.in/kernelcheck.sh
Log:
add kernel version check for arm
Modified: glibc-package/trunk/debian/changelog
Author: pb
Date: 2005-12-25 20:25:30 + (Sun, 25 Dec 2005)
New Revision: 1068
Added:
glibc-package/trunk/debian/patches/arm-socket-weakalias.dpatch
glibc-package/trunk/debian/patches/powerpc-executable-got.dpatch
Modified:
glibc-package/trunk/debian/changelog
Author: pb
Date: 2005-12-25 20:26:01 + (Sun, 25 Dec 2005)
New Revision: 1069
Added:
glibc-package/trunk/debian/patches/strfry-segv.dpatch
Log:
actually add strfry patch
Added: glibc-package/trunk/debian/patches/strfry-segv.dpatch
I think we should just remove the __STRICT_ANSI__ check from
asm/types.h. long long will still work in gcc under -ansi (and, in
fact, will only elicit a warning even under -pedantic) so there should
be no real problem here.
__STRICT_ANSI__'s intended use in header files is to guard
I think we should just remove the __STRICT_ANSI__ check from
asm/types.h. long long will still work in gcc under -ansi (and, in
fact, will only elicit a warning even under -pedantic) so there should
be no real problem here.
__STRICT_ANSI__'s intended use in header files is to guard
On Tue, 2003-12-30 at 18:24, Adam C Powell IV wrote:
It has always happened on my machine for months (though my chroot dpkg
database got trashed a week ago by a crash during an upgrade...), and is
intermittent on the buildd. 0.6.2-1 built fine, 0.6.9-1 failed with
exactly the same
On Tue, 2003-12-30 at 18:24, Adam C Powell IV wrote:
It has always happened on my machine for months (though my chroot dpkg
database got trashed a week ago by a crash during an upgrade...), and is
intermittent on the buildd. 0.6.2-1 built fine, 0.6.9-1 failed with
exactly the same
On Sun, 2003-11-30 at 17:00, Adam C Powell IV wrote:
ldd is returning an error with shlibs on ARM, looks like:
# ldd libluminate.so.3.0.2
not a dynamic executable
Hm, strange. I can't reproduce this here.
[EMAIL PROTECTED]:/usr/lib# ldd libluminate.so.3.0.2
libxml.so.1 =
On Sun, 2003-11-09 at 19:46, Sven Luther wrote:
Well, it should not at least. I will investigate and see if the
linux/fs.h is where it comes from or not. I was not able to find where
the size_t was defined though.
This block of definitions in libparted/linux.c looks kind of
suspicious.
On Sun, 2003-11-09 at 19:46, Sven Luther wrote:
Well, it should not at least. I will investigate and see if the
linux/fs.h is where it comes from or not. I was not able to find where
the size_t was defined though.
This block of definitions in libparted/linux.c looks kind of
suspicious.
On Sat, 2003-11-08 at 21:14, Major A wrote:
After upgrading libc6 on an ARM-based handheld running sarge to
sid, all programs in modutils (lsmod, for instance), issue an error
lsmod: QM_MODULES: Function not implemented and exit when run as
root. When run as non-root, lsmod runs expected, the
On Sun, 2003-11-09 at 00:33, Daniel Jacobowitz wrote:
I'm already fixing this for ia64 in linux-kernel-headers. Mind doing
the same for ARM?
Sure. In fact, I just checked in a patch for that, and was on the point
of preparing an upload. But I guess I'll hang back and let you upload
once
On Sun, 2003-11-09 at 00:33, Daniel Jacobowitz wrote:
I'm already fixing this for ia64 in linux-kernel-headers. Mind doing
the same for ARM?
Ah, maybe I read too much into the present tense there. I guess I'll do
my upload after all.
p.
On Sun, 2003-11-09 at 00:38, Daniel Jacobowitz wrote:
Go right ahead. I meant to say I've already fixed this for ia64 in
the last release, so your analysis is definitely right.
Note that you need to bump glibc's build dependencies for this.
Right, done. Are we planning another source
On Sat, 2003-11-08 at 21:14, Major A wrote:
After upgrading libc6 on an ARM-based handheld running sarge to
sid, all programs in modutils (lsmod, for instance), issue an error
lsmod: QM_MODULES: Function not implemented and exit when run as
root. When run as non-root, lsmod runs expected, the
On Sun, 2003-11-09 at 00:33, Daniel Jacobowitz wrote:
I'm already fixing this for ia64 in linux-kernel-headers. Mind doing
the same for ARM?
Sure. In fact, I just checked in a patch for that, and was on the point
of preparing an upload. But I guess I'll hang back and let you upload
once
On Sun, 2003-11-09 at 00:33, Daniel Jacobowitz wrote:
I'm already fixing this for ia64 in linux-kernel-headers. Mind doing
the same for ARM?
Ah, maybe I read too much into the present tense there. I guess I'll do
my upload after all.
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
On Sun, 2003-11-09 at 00:38, Daniel Jacobowitz wrote:
Go right ahead. I meant to say I've already fixed this for ia64 in
the last release, so your analysis is definitely right.
Note that you need to bump glibc's build dependencies for this.
Right, done. Are we planning another source
On Tue, 2003-10-14 at 17:05, Phil Carinhas wrote:
Installing this package causes all XDM clients to fail to connect to
the XDM server. This was discovered when upgrading Samba to the
samba_3.0.0final-1 version, when it upgraded libc6.
Below is the output of the xdm.log file that shows
On Tue, 2003-10-14 at 17:05, Phil Carinhas wrote:
Installing this package causes all XDM clients to fail to connect to
the XDM server. This was discovered when upgrading Samba to the
samba_3.0.0final-1 version, when it upgraded libc6.
Below is the output of the xdm.log file that shows
On Wed, 2003-10-01 at 05:37, Ian Ward wrote:
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x401660dd in ?? ()
#2 0x40134e2e in ?? ()
#3 0x40134f48 in ?? ()
Seems that some function in a library, maybe libc6, is calling a
On Wed, 2003-10-01 at 05:37, Ian Ward wrote:
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x401660dd in ?? ()
#2 0x40134e2e in ?? ()
#3 0x40134f48 in ?? ()
Seems that some function in a library, maybe libc6, is calling a
On Tue, 2003-09-30 at 05:05, Ian Ward wrote:
munmap(0x4000, 4096)= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Are you able to obtain a backtrace using gdb or catchsegv? We'd really
need to know where in the code it's crashing before we can
On Tue, 2003-09-30 at 05:05, Ian Ward wrote:
munmap(0x4000, 4096)= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Are you able to obtain a backtrace using gdb or catchsegv? We'd really
need to know where in the code it's crashing before we can
On Tue, 2003-09-23 at 03:21, Dirk Morris wrote:
dpkg: error processing /var/cache/apt/archives/libc6_2.3.2-7_i386.deb
(--unpack):
dpkg: warning - old post-removal script killed by signal (Segmentation
fault)
Please check $LD_LIBRARY_PATH and /etc/ld.so.conf, and make sure you
don't have
On Tue, 2003-09-23 at 08:05, bert hubert wrote:
On Tue, Sep 23, 2003 at 12:40:26AM +0900, GOTO Masanori wrote:
works well. (This bug may be introduced in 2003-07-15 Uli's
modification for misc/syslog.c. I guess it's modified for one of libc
cancelation works. But no confidence.)
On Tue, 2003-09-23 at 03:21, Dirk Morris wrote:
dpkg: error processing /var/cache/apt/archives/libc6_2.3.2-7_i386.deb
(--unpack):
dpkg: warning - old post-removal script killed by signal (Segmentation
fault)
Please check $LD_LIBRARY_PATH and /etc/ld.so.conf, and make sure you
don't have
On Tue, 2003-09-23 at 08:05, bert hubert wrote:
On Tue, Sep 23, 2003 at 12:40:26AM +0900, GOTO Masanori wrote:
works well. (This bug may be introduced in 2003-07-15 Uli's
modification for misc/syslog.c. I guess it's modified for one of libc
cancelation works. But no confidence.)
On Fri, 2003-09-19 at 00:41, Daniel Jacobowitz wrote:
bits/libc-lock.h is an installed header, and the public versions of
pthread_cleanup_push call these. I don't think we can do that.
I still haven't heard anything back from the hackers, but I looked at
this a bit more and I think this patch
On Sun, 2003-09-21 at 05:11, Daniel Jacobowitz wrote:
After looking again, I bet you're right. Notice that __libc_pthread_functions
isn't in any installed header. At least, I don't see it anywhere...
Okay, cool. I'm building 2.3.2-8 with this change now; let's see what
happens.
p.
--
To
On Fri, 2003-09-19 at 00:41, Daniel Jacobowitz wrote:
bits/libc-lock.h is an installed header, and the public versions of
pthread_cleanup_push call these. I don't think we can do that.
I still haven't heard anything back from the hackers, but I looked at
this a bit more and I think this patch
On Sat, 2003-09-20 at 14:17, Vincent Zweije wrote:
I suspect xdm needs a restart after the upgrade of libnss_compat.
A simple /etc/init.d/xdm restart is *not* advisable though, as many
(including me) would be thrown out of their root shell in the X session.
Thanks for the report. Do you
On Sat, 2003-09-20 at 14:17, Vincent Zweije wrote:
I suspect xdm needs a restart after the upgrade of libnss_compat.
A simple /etc/init.d/xdm restart is *not* advisable though, as many
(including me) would be thrown out of their root shell in the X session.
Thanks for the report. Do you
On Thu, 2003-09-18 at 13:39, Daniel Jacobowitz wrote:
What were you debugging when you encountered this, and what was loading
libpthread? In general, this won't work. The problem is that syslog
tries to lock a mutex; but the mutex was never initialized because
libpthread was not loaded until
On Thu, 2003-09-18 at 23:36, Philip Blundell wrote:
I'll try adding these functions to __libc_pthread_functions and see if
that helps.
Well, it seems to do the trick with that testcase.
p.
? linuxthreads/sysdeps/pthread/bits/libc-lock.diff
Index: linuxthreads/forward.c
On Fri, 2003-09-19 at 00:41, Daniel Jacobowitz wrote:
bits/libc-lock.h is an installed header, and the public versions of
pthread_cleanup_push call these. I don't think we can do that.
Oh dear. Yes, I suppose the name of the file should have tipped me off
really. Ah well.
p.
--
To
On Fri, 2003-09-19 at 00:40, Daniel Jacobowitz wrote:
OK, one is the PLT reference, the other is the global data. Shouldn't
that global data be fixed up by the loader?
For that to work, the loader would have to remember that it had seen an
unresolved weak reference to those symbols in the GOT,
On Fri, 2003-09-19 at 00:54, Daniel Jacobowitz wrote:
I think the real answer has to be don't do that. Every use of this
idiom breaks with dlopen. This is the worst offender but I'm betting
there are others. __pthread_setspecific seems to be one.
Mmm. I'm not sure that outlawing the use of
On Sun, 2003-09-14 at 11:33, Jacob Kolding wrote:
when using the readdir function from dirent.h to get dirents the
dtype member of dirent is always returned as unknown.
Please supply a test program to demonstrate the problem. We also need
some more information: what filesystem are you using,
On Sun, 2003-09-14 at 13:17, Jacob Kolding wrote:
I'm running ext2 on linux 2.2.20 but a friend of mine is running
reiserfs on 2.4.22 and have the same problem.
I'm not able to reproduce this problem on i386 with kernel 2.4.22 and
libc6 2.3.2-7, on an ext3 filesystem. Once I fixed the
I think this is the cause of the problem:
getdents64(3, 0x80497e0, 4096) = -1 ENOSYS (Function not
implemented)
getdents(3, /* 40 entries */, 3933) = 888
From what I recall, the old-style getdents syscall doesn't return d_type
information. You need to upgrade your kernel to one
On Sun, 2003-09-14 at 16:02, Jacob Kolding wrote:
But a friend of mine has the same problem with kernel 2.4.22 and
reiserfs so how can it be a kernel problem. unless it's at kernel config
option?
attached is the strace from my friend.
In this case, getdents64() is indeed being used
On Wed, 2003-09-10 at 17:28, Steve Doerr wrote:
Any ideas on how I can get more info, or get around this?
You could try adding set -x to the script and invoking it by hand.
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Wed, 2003-09-10 at 20:55, Denis Barbier wrote:
The locales/default_environment_locale question asks whether a locale
should be the default for the whole system. If answer is None,
/etc/environment is untouched, otherwise LANG=$locale is added into
this file. Are there suggestions to make
On Tue, 2003-09-09 at 19:35, Daniel Bonniot wrote:
It seems that setting LC_CTYPE to ISO-8859-1 does not work for
choosing a this specific charset, while setting it to french
works.
I think that's correct behaviour. What leads you to believe that
LC_CTYPE=ISO-8859-1 should be valid?
p.
On Tue, 2003-09-09 at 20:44, Daniel Bonniot wrote:
I think that's correct behaviour.
Then how would you choose that charset?
By selecting a locale that uses the encoding you want. All the LC_*
variables take a locale name as their value.
For instance
On Sun, 2003-09-07 at 20:11, Adam Heath wrote:
Upgrading the kernel is not the way to fix this bug. libc must be fixed.
If the problem is caused by kernel bugs, then upgrading the kernel _is_
the way to fix it.
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On Sat, 2003-09-06 at 16:54, Juergen Kreileder wrote:
The machine (dual PIII) exports several directories to
192.168.1.0/24(rw,sync). The clients have different configurations
(Debian sarge/sid, SuSE, RedHat on i386/SPARC/AMD64), but all use
the same options when mounting the directories
On Sun, 2003-09-07 at 23:29, Jerry Quinn wrote:
printf(%#.0g, d) gives incorrect results in a couple of cases.
The first case has an extra 0 at the end. The second case should be a
fixed point output according to the manpage, not scientific output.
Please supply a test program that
On Sun, 2003-09-07 at 23:27, Juergen Kreileder wrote:
I don't think it's a kernel problem: the combination 2.6.0-test1 and
glibc-2.3.1-17 worked fine while 2.6.0-test1 plus glibc-2.3.2-1
didn't.
Agreed, I don't particularly think it's a kernel problem either. I'm
just trying to understand why
clone 100986 -1
reassign 100986 libc6-dev
reassign -1 manpages-dev
retitle 100986 no manpage for /usr/bin/gencat
retitle -1 missing manpages for some library functions
severity -1 wishlist
thanks
On Fri, 2003-09-05 at 16:21, H. S. Teoh wrote:
reassign 100986 libc6-dev,manpages-dev
thanks
All
)
-- Philip Blundell [EMAIL PROTECTED] Tue, 26 Aug 2003 22:51:03 +0100
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I'm not able to reproduce this bug here. Nikita, please give us some
details about your system. In particular, how many CPUs does it have,
and what type? (I am testing on a single-CPU Athlon.)
Thanks
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
On Sun, 2003-08-31 at 03:00, GOTO Masanori wrote:
Yes, especially enterprise Java environment creates more than 100
threads at the same time. Could you drop this patch?
Okay, I've disabled the patch.
Yes, I agree. Only concern is where do we put ld-linux.so.2 -
/lib/ld-linux.so.2 (i386)
I couldn't reproduce this problem in a quick test with glibc 2.3.2-4 and
nfs-kernel-server 1.0.5-2. Is it still happening for you guys?
Thanks
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Sat, 2003-08-30 at 17:45, GOTO Masanori wrote:
I wonder it's really safe. If we create a lot of threads like Java
EJB environment, we consume virtual memory four times faster than the
current implementation. You find STACK_SIZE is a boundary for each
thread. The right way is to support
On Sat, 2003-08-30 at 18:50, Daniel Jacobowitz wrote:
Or get back to having an i686 libc... this is one of the major
advantages.
Yes, indeed. Did we ever manage to find a way to make upgrades safe
with this? I guess we could ship both the i386 and i686 versions in the
same package, which
On Fri, 2003-08-29 at 08:54, Thomas Morin wrote:
I can't reproduce the segfault if I upgrade to console-tools 1:0.2.3dbs-41,
but I guess this was quite expected since this bug seems to hit binaries
compiled with older glibc, non ?
Kind of. The particular fseek() bug that broke win4lin and so
tags 204691 + pending
thanks
On Fri, 2003-08-29 at 12:20, Brian Almeida wrote:
The solution being offered on the transgaming forums is to increase the stack size
from 2mb to 8mb by applying the following patch to glibc:
Thanks for the information. I don't think this patch is likely to cause
I've no real idea what's going on here. However, since glibc does build
from source just fine for the autobuilders, I guess there must be some
problem with your local build environment.
If you could provide a complete build log, that might help to pinpoint
what's going wrong.
p.
--
To
On Wed, 2003-08-27 at 12:27, Christoph Hellwig wrote:
this seems to be fixed upstream
Looks that way. I'll import those patches into the Debian tree. Thanks
for pointing it out.
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
On Tue, 2003-08-26 at 01:01, Adam Heath wrote:
Is there a debian machine I can access that has this problem?
Yes. You can use vore, unstable chroot.
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
severity 207200 minor
thanks
On Sun, 2003-08-24 at 22:58, Martin Waitz wrote:
libc6-dev shipps /usr/include/linux/udp.h, which includes net/sock.h
however, net/sock.h from linux is not shipped in libc6-dev
if linux/udp.h is not to be used by userspace programs, there is no
value in adding
I'm in the process of building 2.3.2-4 packages. The changelog is
below.
Mostly, this is needed to fix two ARM-related screw-ups that are causing
difficulties for the autobuilder. It should also provide some interim
relief for people suffering from fseek() problems with old binaries.
This
See also:
http://sources.redhat.com/ml/libc-alpha/2003-08/msg00115.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Sat, 2003-08-23 at 04:50, Daniel Jacobowitz wrote:
I've never found the OUTPUT_FORMAT line to be necessary; I simply
delete it in my local builds. But that error is, IIRC, the result of
some minor misconfiguration in the ARM tools. Yeah, I know, that's not
a useful answer - but damned if
Package: libc6
Version: 2.3.2-3
Severity: grave
It seems that libio has changed between 2.3.1 and 2.3.2 in such a way as
to break fseek() for programs that were compiled against glibc 2.0.
http://lists.debian.org/debian-glibc/2003/debian-glibc-200308/msg00218.html contains
some commentary and a
Package: libc6
Version: 2.3.2-3
Severity: grave
Tags: pending
Architecture: arm
It turns out that we had overlooked one other place where glibc uses
waitpid, namely inside popen. I've checked a fix for this into
debian-glibc CVS, and I think corrected kernel-headers should be
forthcoming
On Sat, 2003-08-23 at 17:24, Philip Blundell wrote:
It turns out that we had overlooked one other place where glibc uses
waitpid, namely inside popen. I've checked a fix for this into
debian-glibc CVS, and I think corrected kernel-headers should be
forthcoming imminently as well.
Yow
The crash seems to occur in ptmalloc_init(). I haven't been able to
figure out why exactly the segfault is occurring: all the register
values look OK to me. I think someone with more i386 ski11z needs to
investigate it.
Sebastian reports that if he builds a libc.so from libc_pic.a using
Package: libc6-dev
Version: 2.3.2-2
Architecture: arm
Severity: serious
This can't be good news:
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
*** BUG in libc/scripts/output-format.sed ***
On Thu, 2003-08-21 at 07:43, Adam Warner wrote:
Perhaps it's the same reason that programs compiled against glibc 2.0
performing a fseek() segfault:
http://lists.debian.org/debian-glibc/2003/debian-glibc-200308/msg00218.html
Seems likely. I suspect this is also the cause of Joey Hess's
On Wed, 2003-08-20 at 07:59, [EMAIL PROTECTED] wrote:
I worked around it by upgrading inn from 1.7.2-4 to 1.7.2debian-22.
Wow. Even potato has 1.7.2-16, so 1.7.2-4 must be a really old version.
May I humbly suggest that libc6 2.3.2-2 conflict with inn 1.7.2-4?
This shouldn't be necessary.
On Thu, 2003-08-14 at 05:48, John C Meuser wrote:
It looks like the libc6 upgrade breaks some programs on the system. The
only one's I personally have encountered are consolechars and Win4Lin.
Win4Lin is non-free and difficult for us to work with.
Please give details of how the consolechars
On Fri, 2003-08-08 at 17:53, Guido Guenther wrote:
the mips build fails due to the missing patch I posted in:
http://lists.debian.org/debian-glibc/2003/debian-glibc-200307/msg00154.html
I'd look into why other archs don't need this but my broken laptop
currently leaves me a bit dead in the
On Sat, 2003-08-09 at 11:06, [EMAIL PROTECTED] wrote:
After updating to the latest glibc this morning as per apt-get upgrade,
I now get a segfault on running su -.
What does your nsswitch.conf look like?
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
On Sat, 2003-08-09 at 14:31, Elmar Haneke wrote:
Package: libc6
Version: 2.3.1-17
Severity: critical
Tags: sid
Justification: breaks unrelated software
After installing libc6 2.3.2-2 the win4lin-software does no longer run, it
yust segfaults. Going back to 2.1.3-7 reenables Win4Lin.
I
severity 204706 important
thanks
On Sat, 2003-08-09 at 16:38, GOTO Masanori wrote:
At 09 Aug 2003 16:00:34 +0100,
Philip Blundell wrote:
What package contains Win4Lin?
I guess it's http://www.netraverse.com/.
Ah, yes. Well, I think severity: critical is not appropriate when the
software
I just ran into this bug while testing Jeff's 2.3.2-2 packages. It does
seem rather grave, and will no doubt provoke outrage from users. Since
a patch exists, I think we should try to include it in the packages that
are uploaded to unstable.
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
On Thu, 2003-08-07 at 08:52, GOTO Masanori wrote:
Our long journey for both uploading glibc 2.3.2 to unstable and
cvs.dpatch update to the newer one from Dec 2003 has just arrived a
hopeful important corner. I dupload 2.3.2-2 for unstable after a bit
hours. I believe this 2.3.2 becomes the
I just ran into this bug while testing Jeff's 2.3.2-2 packages. It does
seem rather grave, and will no doubt provoke outrage from users. Since
a patch exists, I think we should try to include it in the packages that
are uploaded to unstable.
p.
On Wed, 2003-08-06 at 01:36, GOTO Masanori wrote:
That's right, it's nice idea to update cvs.dpatch into the latest or
at least 2003-07-22 cvs. I update it later.
I'm a little scared of doing a wholesale update of cvs.dpatch to the
current HEAD just at the minute. Right now we do have a
On Mon, 2003-08-04 at 04:08, GOTO Masanori wrote:
I agree this sparc confusion should be resolved quickly. Hmm, so is
it OK to dupload 2.3.2-2 into unstable? Jeff is offline for a while.
Yes, I think so. Jeff had some concerns about bugs in 2.3.2-2, but I
have been running those packages on
On Mon, 2003-08-04 at 04:08, GOTO Masanori wrote:
I agree this sparc confusion should be resolved quickly. Hmm, so is
it OK to dupload 2.3.2-2 into unstable? Jeff is offline for a while.
Yes, I think so. Jeff had some concerns about bugs in 2.3.2-2, but I
have been running those packages on
On Sat, 2003-08-02 at 13:56, Alastair McKinstry wrote:
I'm raising the severity of this bug to serious, as it breaks
busybox-cvs build on alpha, which in turn breaks the
debian-installer build on alpha.
If you need a quick resolution for that problem, the easiest thing would
be to stop
On Sat, 2003-08-02 at 18:28, Nathanael Nerode wrote:
packages.qa.debian.org claims that 2.3.2-1 was accepted on 2003-07-18.
And that it's out of date on sparc because it needs to be version
2.3.1-17. (?!)
The sparc upload of 2.3.2-1 was mistakenly directed to unstable rather
than
On Sat, 2003-08-02 at 13:56, Alastair McKinstry wrote:
I'm raising the severity of this bug to serious, as it breaks
busybox-cvs build on alpha, which in turn breaks the
debian-installer build on alpha.
If you need a quick resolution for that problem, the easiest thing would
be to stop
On Sat, 2003-08-02 at 18:28, Nathanael Nerode wrote:
packages.qa.debian.org claims that 2.3.2-1 was accepted on 2003-07-18.
And that it's out of date on sparc because it needs to be version
2.3.1-17. (?!)
The sparc upload of 2.3.2-1 was mistakenly directed to unstable rather
than
tags 146489 + upstream
thanks
There was some discussion of this issue on the libc-alpha list at the
time. See http://sources.redhat.com/ml/libc-alpha/2002-05/msg00052.html
and the ensuing thread.
To summarise, Geoff thought that this problem should be fixed in the
kernel, because leaving stale
tags 146489 + upstream
thanks
There was some discussion of this issue on the libc-alpha list at the
time. See http://sources.redhat.com/ml/libc-alpha/2002-05/msg00052.html
and the ensuing thread.
To summarise, Geoff thought that this problem should be fixed in the
kernel, because leaving stale
1 - 100 of 142 matches
Mail list logo
