Package: libc6
Version: 2.36-9
Documentation tells me that
sysconf(_SC_NPROCESSORS_CONF)
get_nprocs_conf()
gives me the upper bound of CPUs and
sysconf(_SC_NPROCESSORS_ONLN)
get_nprocs()
gives the currently online CPUs.
get_nprocs_conf seems to return "possible" value, and it
Hi,
cowdancer: unexpected WIFEXITED status in waitpid
/var/lib/dpkg/info/tzdata.postinst: line 29: /etc/timezone: Cannot allocate
memory
So, the real bug is in cowdancer detecting a weird environment. The
quick workaround would be recreating cowdancer chroot.
cowdancer returns 'ENOMEM' for
Hi,
I'm still seeing that oprofile cannot use libc6-dbg. Anyone seeing the same
problem?
oprofile (opreport -l) gives the following warnings:
warning: /lib/libc-2.6.1.so is not in a usable binary format.
warning: /lib/libdl-2.6.1.so is not in a usable binary format.
warning: /lib/libm-2.6.1.so
Package: libc6
Version: 2.5-9
dlvsym can fail but does not seem to set dlerror(), contrary to the
manpage, which explains that error conditions should check dlvsym=NULL
and dlerror!=NULL, because 0 is a valid address.
The same can be said about dlsym also.
The following code outputs:
I looked in the sources to find a useful testcase, and noticed that
there is no testcase for RTLD_NEXT case. It fails.
$ LD_LIBRARY_PATH=. ./a.out
dlerror() didn't return a string
--- glibc/glibc-2.5/glibc-2.5/elf/resolvfail.c 1999-08-03 04:42:00.0
+0900
+++ resolvfail.c
Hi,
Summary of bug on cowdancer.
430636 was caused by glibc not setting dlerror correctly on failure on
dlvsym(RTLD_NEXT, ...).
430636 happened on amd64 and not on i386 since [EMAIL PROTECTED] is
defined on i386 (non-error-case) and not on amd64 (error-case which is
not reported through
Package: libc6-dbg
Version: 2.3.6.ds1-4
opreport seems to be looking at the file (from strace):
open(/lib/tls/i686/cmov/libc-2.3.6.so, O_RDONLY) = 4
stat64(/lib/tls/i686/cmov/libc-2.3.6.so, {st_mode=S_IFREG|0755,
st_size=1241580, ...}) = 0
open(/lib/tls/i686/cmov/libc-2.3.6.so,
On Sat, Jun 24, 2006 at 12:15:04AM +0200, Denis Barbier wrote:
[...]
As shown above, it seems that there is a bug in glibc.
I cannot reproduce it with libc6 from experimental, so it
looks like it has been fixed in 2.4. My current bet is that
getting libc/iconvdata/jis0208.[ch] from CVS
Package: libc6
I'm filing a bug here in the hope that this bug gets tracked and
fixed. I don't have the time right now (especially over this PHS
connection) to track this problem down. I 'm describing the problem
from memory, so something might be missing. Please do ask if there's
something
Hi,
I'm not suggesting splitting the dirs. Just the way the link is setup.
I'm suggesting creating it in the maintainer scripts instead of the
data.tar.gz so packages that do ship files in (/usr)/lib64 don't make
libc6 unupgradable.
On debootstrap install, libc6 postinst isn't actually ran
When I try to run soundtracker, I get:
soundtracker
*** glibc detected *** free(): invalid pointer: 0xb150 ***
Aborted (core dumped)
This is due to using a newer glibc that gives out core on double-free.
I'm ccing debian-glibc to make sure; is this the case?
In my environment, it's
Hi,
libc.postinst does:
updatercd mountkernfs start 35 S .
/etc/init.d/mountkernfs 2/dev/null || true
is it possible to use invoke-rc.d when possible?
if [ -e /usr/sbin/invoke-rc.d ]; then
invoke-rc.d mountkernfs start
else
Package: libc6
Version: 2.3.2ds1-11
Hi,
libc.postinst does:
updatercd mountkernfs start 35 S .
/etc/init.d/mountkernfs 2/dev/null || true
is it possible to use invoke-rc.d when possible?
if [ -e /usr/sbin/invoke-rc.d ]; then
invoke-rc.d mountkernfs start
else
--- locale.1.orig 2003-01-14 21:30:42.0 +0900
+++ locale.12003-01-14 21:31:13.0 +0900
@@ -233,6 +233,11 @@
.Vb 1
\Metadata about the locale information.
.Ve
+\\s-1LOCPATH\s0
+.PP
+.Vb 1
+\The directory where locale data is stored
At Wed, 29 Jan 2003 09:14:21 +0100,
Alfred M. Szmidt wrote:
Is select() still broken on hurd ?
Try the quoted program and you will know. And if you do try it, tell
us!
I don't run hurd.
I've been walking over old bug reports.
regards,
junichi
--
To UNSUBSCRIBE, email to
Hi,
I've been looking at this bug report, but the SunRPC code
seems to restrict only the redistribution of modified work
as SunRPC itself, and does not restrict redistribution as
glibc, and I would have thought that shouldn't be a problem.
This bug seems to have stagnated, what is going on
reassign 167409 xemacs21
thanks
I think this bug was on xemacs21 side, and I believe that
it is already fixed.
regards,
junichi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
retitle 79358 select() doesn't work properly on hurd
thanks
Is select() still broken on hurd ?
regards,
junichi
quote original text:
When the timeout value in a call to select() is small (less than about
1000 usec) select returns 0, even if the file descriptors have changed.
I'm
I couldn't find any reference to LOCPATH either, but
setlocale seems to look at directories specified by LOCPATH
in addition to (or instead of) the standard location (/usr/lib/locale)
ok, next question is how to write the new definitions to the new
LOCPATH. the outputdir in localedef
Ah, I see. Looks fine to me, so ask Junichi what he was thinking when he
filed the bug ...
What do you think is the actual problem with the fdutils package?
Some explicit hint about what it should do differently would help
me much.
I was thinking wrong.
I have looked at
To ensure some locales are available, I think you can use LOCPATH,
and create locales locally, so that the following are available:
de_DE ISO-8859-1
en_US ISO-8859-1
fr_FR ISO-8859-1
see /usr/sbin/locale-gen on how to generate these locale data.
ok, it's no problem to
I have read the bug logs, and 175655 is supposedly fixed, which means,
174540 should also be closed.
I am assuming that libstdc++ is now rebuilt with new glibc on mipsen,
right ?
regards,
junichi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
Package: base-passwd,exim,fdutils,libc6
I've grepped for noninteractive on my system.
see man-db for a better examble.
if [ $build_db -eq 1 ]; then
frontend=`echo $DEBIAN_FRONTEND | tr '[:upper:]' '[:lower:]'`
if [ $frontend = noninteractive ]; then
# Run in the foreground. In
Package: nntp
Version: 1.5.12.1-14
Severity: serious
nntp fails to build from source on i386, when doing a rebuild inside chroot.
I am filing this bug to notify you that I failed to build your
package from source in the current sid distribution.
It is a serious problem that your source does not
Package: nntp
Version: 1.5.12.1-14
Severity: serious
nntp fails to build from source on i386, when doing a rebuild inside chroot.
I am filing this bug to notify you that I failed to build your
package from source in the current sid distribution.
It is a serious problem that your source does not
I'm glad to hear GNU Emacs builds fine. What version? (Ie, if it's
recent CVS there's some chance that they've already dealt with the
glibc change. I have a couple more reports, I'm reasonably sure
that the glibc change is it.)
I believe the version in Debian is not the bleeding edge CVS
I'm glad to hear GNU Emacs builds fine. What version? (Ie, if it's
recent CVS there's some chance that they've already dealt with the
glibc change. I have a couple more reports, I'm reasonably sure
that the glibc change is it.)
I believe the version in Debian is not the bleeding edge CVS
At Sat, 02 Nov 2002 15:42:17 +0900,
Stephen J.Turnbull [EMAIL PROTECTED] wrote:
I would assume this will also affect GNU Emacs and possibly other
applications that use unexec to build preloaded versions.
emacs21 seems to build fine.
regards,
junichi
At 02 Nov 2002 02:10:37 -0500,
Jeff Bailey wrote:
[1 text/plain (quoted-printable)]
On Sat, 2002-11-02 at 01:42, Stephen J.Turnbull wrote:
After upgrading to glibc 2.3.1, I can't build XEmacs without the
portable dumper
Please provide the text of the actual error message.
It failed
Dumping under the name xemacs
Testing for Lisp shadows ...
Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
Ugh. I don't know elisp at all. I'll need someone else to do some
analysis on this to figure out what's up.
It's not
At Sat, 02 Nov 2002 15:42:17 +0900,
Stephen J.Turnbull [EMAIL PROTECTED] wrote:
I would assume this will also affect GNU Emacs and possibly other
applications that use unexec to build preloaded versions.
emacs21 seems to build fine.
regards,
junichi
--
To UNSUBSCRIBE, email to
Package: bigloo,libc6
Severity: grave
Version: 2.5b+really2.5c-beta-2002-10-18-1
I've encountered this problem while trying to compile scribe.
Full build log is available at:
http://www.netfort.gr.jp/~dancer/software/failed-log/scribe.log
It seems to be some internal symbol.
.
Package: libc6
Version: 2.3.1-1
I've seen this error during ppxp-applet build:
/bin/sh ../libtool --mode=link gcc -DKITAME_HACK -g -O2 -Wall -o ppxp-applet
ppxp-applet.o ui.o ppxp-object.o property.o -rdynam
ic -L/usr/lib -L/usr/X11R6/lib -rdynamic -lgnomeui -lart_lgpl -lgdk_imlib -lSM
On Sun, 20 Oct 2002 06:18:08 -0700
Jeff Bailey [EMAIL PROTECTED] wrote:
/home/takuo/work/debian/ppxp-0.2001080415/lib/ppxp.c:473: undefined
reference to `__ctype_b'
collect2: ld returned 1 exit status
make[3]: *** [ppxp-applet] Error 1
make[3]: Leaving directory
34 matches
Mail list logo
