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 t
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
The following command in chapter 6's glibc:
make -k check >glibc-check-log 2>&1
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
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.
--
http://linuxfromsc
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,
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
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
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, 2006 at 01:11:28PM -0600, Archaic wrote:
> I would think intel/amd is sufficient if even that is necessary. It
> would be easy to go overboard on this, though. As for jhalfs versus my
> logs, if the test output was separated from the rest, then it is
> feasible, other wise we are ta
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 usefu
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 believe
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
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 sayi
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
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 documentat
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
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 te
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 se
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
currently
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 sgm
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
21 matches
Mail list logo
