Matthew Burgess wrote:
1) Package freeze (Wed. 24th)
2) Cut an RC1 (Wed. 24th)
3) Release (Wed. 31st)
Sorry, I cannot agree with this plan.
1) BLFS still has http://wiki.linuxfromscratch.org/blfs/ticket/1957 . Since BLFS
has marked this as WONTFIX, the fact that BLFS includes known broken
Alexander E. Patrakov wrote:
1) BLFS still has http://wiki.linuxfromscratch.org/blfs/ticket/1957 .
Since BLFS has marked this as WONTFIX, the fact that BLFS includes known
broken applications without notice must be mentioned in LFS, and support
should be disclaimed completely. Ideally, it shoul
Jeremy Huntwork wrote these words on 05/22/06 08:52 CST:
> I think I understand your concern here. A note in BLFS saying that
> multibyte locale support in LFS/BLFS is new and not fully tested for
> each package, along with the reminder to check the wiki for user notes
> should suffice don't yo
On 5/22/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
On the 'Locale Related Issues' page in BLFS it opens with:
"This page contains information about locale related problems and
issues. In this paragraph you'll find a generic overview of things
that can come up when configuring your system for
Jim Gifford wrote:
We in CLFS have our udev rules. LFS has their udev rules. BLFS is
going to have their rules. Here is what I'm proposing.
Making a unified package of rules, with targets make install-lfs
and make install-clfs.
Rather than creating a whole new package, why don't you
Matt,
The issue is that CLFS had a udev package that was tested and now
that LFS has a udev package that has been tested, it just doesn't make
sense to have multiple packages with the same rules. In CLFS we do have
some additional rules, but many of them are the same. Numerous times
i've be
r3al1tych3ck wrote:
Sorry Bruce. Not embarrassed here. It took almost half an hour to
explain it in irc before because the hot headed people would not listen.
Eventually they got it but are still to smug to do anything about it.
SURE. I, you, or anyone can point to any ONE place in the book
Matthew Burgess wrote:
> Rather than creating a whole new package, why don't you just list what
> you don't like about the current LFS rules? Or has this been done
> before and I missed it?
As far as I know both sets of rules work exactly as they're intended to.
There is nothing wrong with either
One more point, is that both CLFS and LFS are both trying to get to a
release point in June, but to a lot of us this is an issue that needs to
be resolved.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information pag
Well, if you or the OP can provide definitive examples of where the
book is inconsistent then I will gladly reword it. As it is, the
introduction sections of each chapter are the only places where I am
aware we inform you of what user you should be, and it is assumed that
one reads that in
Jim Gifford wrote:
In CLFS we do have some additional rules, but many of them are the same.
So why don't you just drop the ones that are the same, leaving you with
just the additional rules required for CLFS?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromsc
On Mon, May 22, 2006 at 12:06:21PM -0700, Jim Gifford wrote:
>
> Making a unified package of rules, with targets make install-lfs
> and make install-clfs. Going through each of the rules and figure out
> which are common and which are specific. If that won't work, still have
> a unified pa
Matt Darcy wrote:
The LFS book is fine in terms of wording, there is a slight room for
improvment in the cross book due to the chroot/boot options and the lead
into that.
Thanks for the clarification, Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscr
This is been a topic of many different discussions. A lot of people have
tried to convince both sides, but nothing has ever been settled. It
needs to be settled before this rift between projects gets any bigger.
We in CLFS have our udev rules. LFS has their udev rules. BLFS is
going to have
Jim Gifford wrote:
This is been a topic of many different discussions. A lot of people
have tried to convince both sides, but nothing has ever been settled.
It needs to be settled before this rift between projects gets any bigger.
We in CLFS have our udev rules. LFS has their udev rules. B
Archaic wrote:
Thanks a lot for the plagarism. This is the same proposal I made to you
in a private email (and one where you never gave any comment).
Just my $0.02 but...
WHY are you trying to discuss this privately? This seems perfectly
appropriate for lfs-dev, and a good solution that most
Justin R. Knierim wrote:
Archaic wrote:
Thanks a lot for the plagarism. This is the same proposal I made to you
in a private email (and one where you never gave any comment).
Just my $0.02 but...
WHY are you trying to discuss this privately? This seems perfectly
appropriate for lfs-dev, and
On Mon, May 22, 2006 at 02:16:42PM -0700, Justin R. Knierim wrote:
>
> WHY are you trying to discuss this privately?
Many if not most proposals are first formed off list. If a couple of
developers manage to hash something out that seems reasonable, then it
goes on list for finalization. This is n
On Mon, May 22, 2006 at 02:26:49PM -0700, Jim Gifford wrote:
> >
> That was the point of this thread, Archaic, I said after Ryan and I
> discussed this I would post a response. So let's just forgot the whole
> thing and leave both projects separate.
Jim, you didn't post a response. You posted a
Archaic,
I'm tired of this constant fighting crap between the projects, you
can take credit for everything.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
I propose to change the stripping instructions from:
strip --strip-debug /tools/lib/*
strip --strip-unneeded /tools/{,s}bin/*
to:
strip -x /tools/lib/*
strip /tools/{,s}bin/*
"strip -x" strips all non-global symbols, not only debug ones,
which produces smaller
I noticed that in the chapter 6, glibc-2.3.6 will fail to compile,
because the gcc specs patch is preventing glibc from including the
kernel headers at /usr/include, adding the option --with-headers should
solve the problem.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www
Some test related to symbols will fail when compiling binutils with -O3
or -finline-functions (because of inlined functions), but binutils
should be ok. It's a good idea to put a note about it, or maybe add
instructions to patch the tests makefiles to use -fno-inline-functions.
--
http://linuxfr
tic complains about an undefined symbol (_nc_check_termtype2),
when installing ncurses.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 5/22/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
We in CLFS have our udev rules. LFS has their udev rules. BLFS is
going to have their rules. Here is what I'm proposing.
Making a unified package of rules, with targets make install-lfs
and make install-clfs. Going through each of the
Ismael Luceno wrote:
I noticed that in the chapter 6, glibc-2.3.6 will fail to compile,
because the gcc specs patch is preventing glibc from including the
kernel headers at /usr/include, adding the option --with-headers should
solve the problem.
You must have applied the wrong patch then.
Ismael Luceno wrote:
Some test related to symbols will fail when compiling binutils with -O3
or -finline-functions (because of inlined functions), but binutils
should be ok. It's a good idea to put a note about it, or maybe add
instructions to patch the tests makefiles to use -fno-inline-function
Without patching, the pc file installs unaltered (@VARIABLE@ in place of
proper values). I changed the values to what I thought they should be
on the fly. This is different than what I have from the 1.2.8 version.
I assumed the patch was not needed as the pngtest compile line
contained -lz a
28 matches
Mail list logo
