On 9/19/06, Bryan Kadzban <[EMAIL PROTECTED]> wrote:
Actually, these rules will require udev-098 or higher, which isn't in
the book yet -- which means if I commit this change, we'll have to hold
off on building the udev-config tarball until we update the udev
version. (It's easy enough to skip
Matthew Burgess wrote:
> but I had the same doubt as you as to why we'd want to walk the tree,
> hence I assumed I was in need of a cluebat :-)
Well, most of the time it may not be needed. But I figure if the old
rules did it, the new ones probably should as well. At least for now.
> Feel free
Well I have about the same schedule as you Robert, but I am willing to
throw my hat in the ring to help maintain HLFS-Stable. I have a big interest in
seeing that we can work out a hardened system capable of being used for stable
server environments. I think that starting another branch
On 9/19/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
>
Matt, I agree, but, what I think is wrong is the idealism that David
Woodhouse has on this, he doesn't care if something breaks. A really
good example here is iptables. How would you suggest handling that can
of worms.
The thing is, it's not
Jim Gifford wrote:
Matt, I agree, but, what I think is wrong is the idealism that David
Woodhouse has on this, he doesn't care if something breaks. A really
good example here is iptables. How would you suggest handling that can
of worms.
As per my proposal above, patch iptables to fix the bu
Matthew Burgess wrote:
Jim Gifford wrote:
This means userspace still will be broken until we submit patches to
the upstream maintainers for the programs that are broke.
And that's exactly what my proposal suggested we tackle. The way I
see it, if a package fails to build using the headers_i
Hi,
another think I just found out. Glibc's sunrpc has it's own impl of DES.
As noted in sunrpc/des_impl.c: Collected from libdes and modified for
SECURE RPC by Martin Kuck 1994, funny huh?
:]
signature.asc
Description: OpenPGP digital signature
--
http://linuxfromscratch.org
Jim Gifford wrote:
This means userspace still will be broken until we submit patches to the
upstream maintainers for the programs that are broke.
And that's exactly what my proposal suggested we tackle. The way I see
it, if a package fails to build using the headers_install kernel headers
i
Hi,
> It shouldn't be hard to remove libcrypt from glibc
We'll have to build it later as it defines crypt(). Maybe we could only
replace it's MD5 algo with OpenSSL's and build it separately once
libcrypto is in place...
# EOF
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://w
Dan Nicholson wrote:
> On 9/19/06, Stef Bon <[EMAIL PROTECTED]> wrote:
>>
>> in the current book the version of openldap is 2.3.20. This is not an
>> stable version!!! A lot of bugs as I found out when modifying a
>> ldapdirectory with ldbm backend.
>>
>> The current stable 2.3.27 is much better!
On 9/19/06, Stef Bon <[EMAIL PROTECTED]> wrote:
in the current book the version of openldap is 2.3.20. This is not an stable
version!!! A lot of bugs as I found out when modifying a ldapdirectory with
ldbm backend.
The current stable 2.3.27 is much better!
Thanks, Stef. There's a bug for this
Hello,
in the current book the version of openldap is 2.3.20. This is not an stable
version!!! A lot of bugs as I found out when modifying a ldapdirectory with
ldbm backend.
The current stable 2.3.27 is much better!
Stef Bon
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://
Dan Nicholson wrote:
On 9/18/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
Matt,
David will not listen to this, I have tried. His words are, it's not
userspace submit patches to the actual program maintainer.
Jim,
I'm sorry, but I've read this a few times now and I can't understand
what the
On 9/18/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
Matt,
David will not listen to this, I have tried. His words are, it's not
userspace submit patches to the actual program maintainer.
Jim,
I'm sorry, but I've read this a few times now and I can't understand
what the second sentence means.
14 matches
Mail list logo