In article <[EMAIL PROTECTED]> Branden writes:
>> I can't believe he actually intends to keep it like this..
>I'm going to #define DEV_RANDOM /dev/random for Linux systems.
And Debian Hurd? Or does the Hurd not have /dev/random or /dev/urandom?
I suspect that /dev/urandom may be the better cho
In article <[EMAIL PROTECTED]> Kusti writes:
>I believe the /dev/mem gets read only in systems where no /dev/(u)random
>exists.
Actually, the standard configuration is that /dev/mem is read. The
code to read from /dev/(u)random isn't activated in any situation in
the standard upstream X distrib
[Apologies to readers of debian-sparc, who have already received a copy of this]
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] write:
[XDM randomness]
>/dev/random? /dev/urandom? You are kidding. This randmomness is used
>to create authorisation cookies for X which in my understanding provide
In article <[EMAIL PROTECTED]> you write:
>Blech; it would appear fakeroot does an explicit dlopen of
>/lib/libc.so.6. Since I don't have root in your chroot, and, well,
>fakeroot doesn't work, try changing LIBCPATH at the top of libfakeroot.c
>to /usr/lib/libc.so.12 and recompiling..
>
Oh, yes
In article <[EMAIL PROTECTED]> you write:
>
>--8EbpmHtzgx
>Content-Type: text/plain; charset=us-ascii
>Content-Description: message body text
>Content-Transfer-Encoding: 7bit
>
>Hi,
>
>chroot /debian /bin/bash is SEGVing on me; attached is the output of
>ktrace -i chroot /debian /bin/bash; kdump.
>
In article <[EMAIL PROTECTED]> you write:
>EVentually yes, but it may well be that we no longer need this system
>by the time we are stable enough for a formal autobuilder. I'm
>certainly willing to build packages from this tree and make them
>appear in MIT AFS space, which is web accessible.
>
I
6 matches
Mail list logo
