tags 298913 + pending
thanks
On Thu, 2005-03-10 at 17:16 +, Colin Watson wrote:
Attached is a patch that implements a --keep-existing flag, with
documentation. It relies on perl-base to figure out whether the locale
exists, but perl-base is Essential so that should be OK. Run 'make' in
On Mon, 2005-09-05 at 21:10 +0200, Wolfgang Leister wrote:
As you can see from the example the install tries to uninstall
initrd-tools and all installed kernels. This makes that I cannot upgrade
some other packages that depend on a newer version of libc6.
This is caused by libc6's Conflict
On Tue, 2004-08-10 at 14:41 -0500, Jeff Licquia wrote:
When the GLOB_APPEND flag is passed to glob(), the call is supposed to
tack new results on to the ones already represented in the glob_t passed
in. If there is an error, partial results may be added, but the
original glob_t should
On Fri, Apr 16, 2004 at 09:13:42PM -0700, Ryan Murray wrote:
Just to make it clear to everyone involved -- #133578 is waiting for #214898
to be fixed in glibc. I'm not going to parse/use a tool to read the PAM
configuration file /etc/environment. That config file is for setting up
the
tags 344954 + pending
thanks
On Tue, 2005-12-27 at 17:39 -0500, Joey Hess wrote:
The validlocale program is currently part of base-config, but
base-config is going away. validlocale needs a new home ASAP and locales
seems like the best place.
Seems reasonable to me. I've checked this into
On Mon, 2005-09-19 at 23:07 +0400, Nikita V. Youshchenko wrote:
[EMAIL PROTECTED]:~ echo -n | fakeroot awk '{print}'
awk: relocation error: awk: symbol _dl_catch_error, version GLIBC_PRIVATE not
defined in file ld-linux.so.2 with link time reference
This is fixed in post-sarge gawk
On Wed, 2005-12-28 at 22:34 +0100, Denis Barbier wrote:
thanks for taking care of translated manual pages, but the po/
directory needs to be checked in too. OTOH you may remove
xx/validlocale.xx.8 files (they are generated during the build)
and fr/termwrap.add (it was needed for the termwrap
reassign 314616 no-ip
thanks
Glibc's standard behaviour is to cache the contents of /etc/resolv.conf
across multiple calls to gethostbyname(). I doubt this will change any
time soon.
The solution to this bug is probably for no-ip to call res_init() prior
to attempting resolution, if it suspects
The llseek problem is caused by a kernel bug. I thought that the
2.2.19 netwinder kernels in Debian had been patched to fix this, but I
guess I was mistaken about that. Anyway, there isn't a great deal that
we can do in glibc to fix the underlying problem.
I guess we could add a check to
tags 222536 unreproducible
thanks
On Tue, 2003-12-30 at 18:24, Adam C Powell IV wrote:
Can you try to build illuminator, and see if the problem occurs?
I ran a build of illuminator in the unstable chroot on smackdown (the
user chroot, not the buildd one) and it worked fine. So, I don't really
on Sat, Nov 08, 2003 at 08:43:07PM -0800, Jeff Bailey wrote:
I was hoping to wait until BenC (or another Sparc porter) came up with
the solution for the sparc64 borkage.
Okay. I've uploaded 2.3.2.ds1-10.0.1 as a binary NMU. It seems to fix
the modutils problem.
p.
on Mon, Sep 01, 2003 at 01:07:57PM +0200, Josselin Mouette wrote:
Interesting point.
I'm still experiencing the same issues with regxpcom and gcc -ldl, but
I'm afraid there is no such explanation on my system. LD_LIBRARY_PATH is
unset, and I have no other copies of glibc lying around.
Thanks.
12 matches
Mail list logo
