Tushar Teredesai wrote:
No there should not be any duplication. LFS would have the base udev
rules and bootscripts. CLFS, HLFS and BLFS would add to it with their
unique modifications. The approach has worked nicely for the
bootscripts, the same would work for udev rules.
I totally disagree,
El Sábado, 27 de Mayo de 2006 06:18, Alexander E. Patrakov escribió:
1) The translation must be done with the same DocBook XML tools as the
English book, and a link to the DocBook source must be provided
2) The translation should be compatible with jhalfs, and the non-obvious
differences in
M.Canales.es wrote these words on 05/27/06 04:01 CST:
Actually, running jhalfs on both the original book and the translated book
and
diffing the output is the best way to be sure that the commands and
packages/patches versions in both books are identical.
You may want to see if the
Tushar Teredesai wrote:
IMO, the best solution is the one suggested by Matt. LFS should
contain the udev rules and bootscripts for LFS. All dependent projects
should work off that base and release their own additions (or
deletions in form of patches) - similar to how the bootscripts are
On Sat, 2006-05-27 at 04:31 +0100, Declan Moriarty wrote:
On Fri, 2006-05-26 at 18:40 -0400, Robert Connolly wrote:
On May 26, 2006 01:35 pm, George Boudreau wrote:
If Robert says he has built a
hlfs(svn)- hlfs(svn) then that is the end of the story and I will look
at my setup.
I
El Sábado, 27 de Mayo de 2006 13:13, Randy McMurchy escribió:
You may want to see if the sgmldiff program from docutils can help.
It may work with XML just fine. And if so, it sounds like it may
help.
That type of tools help comparing XML trees, but not CDATA.
CDATA (the actual output text)
On 5/26/06, Alexander E. Patrakov [EMAIL PROTECTED] wrote:
In order to avoid these situations in the future, I propose to change the
requirements for translations mentioned on our official site. The proposal is
going to be effective since LFS-6.2, and it is NOT a licensing change (i.e.,
anyone
On Sat, May 27, at 07:32:49 Dan Nicholson wrote:
Should have replied before. I think it's worth it to be consistent.
As long as we have the commands (and you just did the work for me),
then we might as well put them in the book. Randy puts in long
instructions for rebuilding documentation
Andrew Benton wrote these words on 05/27/06 08:39 CST:
Tushar Teredesai wrote:
[snip plan to keep things as they are, per Matt's suggestion]
+1
So this means that 4 editors within the project (and I'd a coke
that it would be 5 if Bruce weren't on vacation and offered an
opinion) thinking
Randy McMurchy wrote:
So this means that 4 editors within the project (and I'd a coke
that it would be 5 if Bruce weren't on vacation and offered an
opinion) thinking keeping things the same (using LFS as the base
for all, and other projects fill in holes) is the right thing to
do.
I'm only
Jim Gifford wrote:
I lot of people are afraid to say things because they will be attacked
on these lists, so they sit back and go with the flow. That's part of
the problem also, when your community is afraid to speak up there is
something wrong.
So how can we accurately judge the popularity
Hello Everyone,
After reviewing LFS in preparation for the changes that went in with
r7632, I saw again the note (previously in gcc-pass2, but now in
chapter06/gcc) which suggests comparing your gcc test results to what's
here: http://www.linuxfromscratch.org/lfs/build-logs/development/
I
On Sat, May 27, 2006 at 12:22:47PM -0600, Jeremy Huntwork wrote:
I believe that, previously, Archaic was creating these build logs with
his personal scripts, which up to now has been sufficient.
Not just previously. Still.
Now, however, we have perhaps a opportunity to increase the
El Sábado, 27 de Mayo de 2006 21:20, Jeremy Huntwork escribió:
I don't really care what scripting method does it, I just liked the idea
of archiving the results of several builds. jhalfs might make this very
easy and practical. You're right that the test-results only are
required. Manuel,
On Sat, May 27, at 10:39:19 Jim Gifford wrote:
I lot of people are afraid to say things because they will be attacked
on these lists, so they sit back and go with the flow. That's part of
the problem also, when your community is afraid to speak up there is
something wrong.
Please let's
Matt,
They read the list, but they don't trust people on these lists.
Everytime someone brings up a proposal, people blow up. You can't make a
guarantee that they won't get flamed for making a suggestion.
If we move things to neutral parties, this would be a compromise that
everyone will
Jim Gifford wrote:
Everytime someone brings up a proposal, people blow up.
Please stop with this everybody and everytime hyperbole, Jim.
You can't make a guarantee that they won't get flamed for making a suggestion.
That, of course, depends on how sensible the suggestion is. Actually,
no
Ok, it's settled then, LFS will have their rules, and CLFS will have
their own. So much for unification.
I still welcome Dan and Alex to maintain the CLFS udev rules, if they
choose.
I will also welcome DJ and Conathan to work on the CLFS bootscripts, if
they choose.
--
The following command in chapter 6's glibc:
make -k check glibc-check-log 21
Could stand with a bit of modification so it outputs to both the screen
as well as the log file. As it is, there is no output on the screen at
all, which is so unlike any other make and make check run from
Gerard Beekmans wrote these words on 05/27/06 19:48 CST:
Could stand with a bit of modification so it outputs to both the screen
as well as the log file. As it is, there is no output on the screen at
all, which is so unlike any other make and make check run from the book.
I'll agree that it
Randy McMurchy wrote:
It can only slow you down (sometimes significantly), and there is
I tend to look at things from the other way around: if you are one of
few who is slowed down by this (remote builds), then you probably make
other changes already since most every single other command in
21 matches
Mail list logo
