Randy McMurchy wrote:
There would be some who disagree about expecting developers to have
run all the tests with all the proper prerequisites in place. *Many*
times this is impossible.
Package Foo depends on package Bar. Package Foo's test suite does
many things to check proper operation with pa
Gerard Beekmans wrote:
> If a symlink allows us to leave grep in its proper location in the
> alphabet, I don't see a problem with that. We just want to make sure
> that grep's "make install" replaces the symlink rather than overwrite
> the target in /tools.
>
As much as an alphabetical branch mak
Bruce Dubbs wrote:
$ time for file in /tmp/subversion/*; do if [ $file != lost+found ];
then rm -r $file; fi; done
real0m0.981s
$ time find . -xdev -mindepth 1 ! -name lost+found -delete
real0m0.501s
Both are too close to be of much value. A test like the one you did
before with
Randy McMurchy wrote:
> On Fri, 2006-03-03 at 17:38 -0600, Bruce Dubbs wrote:
>
>> GPhoto2 seems to fit in the same place that Gimp is located: Individual
>> Office Programs.
>
> Man am I confused. And here I thought GPhoto2 was nothing more than a
> utility to download stuff from a still camer
Gerard Beekmans wrote:
> David Fix wrote:
>> The for construct doesn't have this issue. :)
>
> Good to know.
>
> Bruce, since you brought this up, can you run a test to see if the "for"
> method is faster than using find?
>
> The way we use it, a recursive find in /tmp or a "rm -r /tmp/*" in a
On Fri, 2006-03-03 at 17:38 -0600, Bruce Dubbs wrote:
> GPhoto2 seems to fit in the same place that Gimp is located: Individual
> Office Programs.
Man am I confused. And here I thought GPhoto2 was nothing more than a
utility to download stuff from a still camera. A very good utility
that suppor
Dan Nicholson wrote:
> On 3/3/06, Richard A Downing <[EMAIL PROTECTED]> wrote:
>> I've written two wiki pages, Libgphoto2 and GPhoto2, as a start of set
>> of packages on the general theme of Digital Photography.
>>
>> There doesn't seem to be a good place to link these into the index.
>>
>> What i
Dan Nicholson wrote:
than being moved in the order, speak now or forever hold your peace.
As indicated in an earlier email today I didn't see a technical reason
for moving the package. I'm starting to lean more toward a simple symlink.
--
Gerard Beekmans
/* If Linux doesn't have the solutio
On 3/3/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> On 3/3/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> >
> > In summary, having automake and libtool before autoconf enables 3 of
> > the 183 total tests in the autoconf test suite. Now to see what
> > happens with automake.
>
> When building au
Chris Staub wrote:
I've started listing every package dependency (will even include what's
already in the book) here -
http://linuxfromscratch.org/~chris/dependencies.txt - it's easy to lose
That list looks fine to me.
track in the bug so it's good to have all the info in one place. Also, I
On 3/3/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
>
> In summary, having automake and libtool before autoconf enables 3 of
> the 183 total tests in the autoconf test suite. Now to see what
> happens with automake.
When building automake, if libtool is present 29 more tests of the
total 567 are
Dan Nicholson wrote:
Libtool enables 1 more test which passes. 8 more tests are skipped
because Fortran isn't there. Add fortran to /tools? :-)
No, I don't think so. but Java and OOo might be useful there...
I'll let you set that up. ;)
--
JH
--
http://linuxfromscratch.org/mailman/listinfo
On 3/3/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> On 3/3/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> >
> > I'll try to quantify how much missing the different packages affects
> > the test coverage. Unless Chris has done this already.
>
> Having automake enables 2 more tests out of the 183
On 3/3/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
>
> I'll try to quantify how much missing the different packages affects
> the test coverage. Unless Chris has done this already.
Having automake enables 2 more tests out of the 183 total for
autoconf. One of which failed for me because I had a
Chris Staub wrote:
Any problem with keeping libtool where it is and moving autoconf and
automake below libtool?
Not in my mind.
There is something to be said for having autoconf and automake as early
on in chapter 6 as possible by the way. We may encounter a patch some
day that requires runn
Gerard Beekmans wrote:
A symlink is less work than moving the package itself and the move has
no added benefit as far as I can tell.
I'm changing my vote from moving grep to symlink grep unless a valid
technical reason comes up that warrants not using a symlink. We should
still move libtool
Richard A Downing wrote these words on 03/03/06 11:49 CST:
> I've written two wiki pages, Libgphoto2 and GPhoto2, as a start of set
> of packages on the general theme of Digital Photography.
>
> There doesn't seem to be a good place to link these into the index.
>
> What is suggested?
I would sa
On 3/3/06, Richard A Downing <[EMAIL PROTECTED]> wrote:
> I've written two wiki pages, Libgphoto2 and GPhoto2, as a start of set
> of packages on the general theme of Digital Photography.
>
> There doesn't seem to be a good place to link these into the index.
>
> What is suggested?
Glad to see it,
I've written two wiki pages, Libgphoto2 and GPhoto2, as a start of set
of packages on the general theme of Digital Photography.
There doesn't seem to be a good place to link these into the index.
What is suggested?
Richard.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://w
David Fix wrote:
The for construct doesn't have this issue. :)
Good to know.
Bruce, since you brought this up, can you run a test to see if the "for"
method is faster than using find?
The way we use it, a recursive find in /tmp or a "rm -r /tmp/*" in a
for-loop has the exact same result.
Randy McMurchy wrote:
single test suite run successfully, I'm just trying to present a
point of view that it is not reasonable to expect developers to
to the amount of testing that Bruce suggests.
I agree with Randy here. It only makes sense after all. Throughout the
life cycle of LFS we use a
Dan Nicholson wrote:
I'll try to quantify how much missing the different packages affects
the test coverage. Unless Chris has done this already.
No, I've just been looking at dependencies...haven't actually kept track
very much of exactly *what* each dependency affects.
I'm doing this now. W
On 3/3/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> On 3/3/06, Chris Staub <[EMAIL PROTECTED]> wrote:
> > >
> > > Autoconf itself certainly is just a tiny package, but it also requires
> > > several additional Perl modules that are not currently not built there.
> >
> > Of course, by "there" I me
On 3/3/06, Chris Staub <[EMAIL PROTECTED]> wrote:
> >
> > Autoconf itself certainly is just a tiny package, but it also requires
> > several additional Perl modules that are not currently not built there.
>
> Of course, by "there" I mean "in /tools".
Ah, good. I forgot about that. Thanks, Chris.
Bruce Dubbs wrote these words on 03/03/06 10:40 CST:
> I don't think it is unreasonable to assume the developers
> have run all the tests with all the proper prerequisites in place before
> releasing a stable package.
Not trying to totally disagree with Bruce's take, I'd like to
present a differe
Bruce Dubbs wrote:
Gerard Beekmans wrote:
Dan Nicholson wrote:
So far, the votes are:
Me: Move up libtool and grep, note about missing automake
Chris: Same
Our use of the test suites is a pleasant side effect to give us
assurance that we built the package properly, but we shouldn't obsess
ab
Matthew Burgess wrote:
> Actually, if we were to replace Vim with Emacs we could have the editor
> available early and retain alphabetical order too. Very much :-)
If we used emacs, we wouldn't need anything else. Isn't it an operating
system? :)
-- Bruce
--
http://linuxfromscratch.org/ma
Gerard Beekmans wrote:
> Dan Nicholson wrote:
>> So far, the votes are:
>> Me: Move up libtool and grep, note about missing automake
>> Chris: Same
>> Jeremy: Add note about missing automake and libtool
>
> From the sounds of it, grep and libtool can be moved up the chain
> without side effects. L
Dan Nicholson wrote:
So far, the votes are:
Me: Move up libtool and grep, note about missing automake
Chris: Same
Jeremy: Add note about missing automake and libtool
From the sounds of it, grep and libtool can be moved up the chain
without side effects. Let's go for it. Having less tests skipp
Chris Staub wrote:
Dan Nicholson wrote:
On 3/3/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
Nah, probably not for the book. In general, I don't mind adding stuff
to /tools. After getting bent over by gcc and glibc for multiple
hours, I don't see the harm in tossing one more tiny package on
Dan Nicholson wrote:
On 3/3/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
Dan Nicholson wrote:
1. automake depends on autoconf and autoconf test suites depends on
automake. This is circular. The only way to solve it is to add one
or the other to /tools or to live with less test coverage in
Randy McMurchy wrote:
And, unfortunately for me, what's made me feel like even more of an
idiot, is that after his two messages to try and explain it, I still
don't have a clue.
Not sure if this will help, but the entire purpose of these changes is
to document dependencies. Since LFS is linear
On 3/3/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> Nah, probably not for the book. In general, I don't mind adding stuff
> to /tools. After getting bent over by gcc and glibc for multiple
> hours, I don't see the harm in tossing one more tiny package on the
> heap. But, in this case, I think
Chris Staub wrote these words on 03/03/06 09:29 CST:
> I'm sorry, you're right, that comment was not needed...I was typing
> without really thinking. I will (attempt to) keep from doing that again.
No sweat. Everything's cool. I just read Dan's message and he requested
input. I tried. I obviousl
On 3/3/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote:
> > 1. automake depends on autoconf and autoconf test suites depends on
> > automake. This is circular. The only way to solve it is to add one
> > or the other to /tools or to live with less test coverage in autoconf.
>
Jeremy Huntwork wrote:
Dan Nicholson wrote:
1. automake depends on autoconf and autoconf test suites depends on
automake. This is circular. The only way to solve it is to add one
or the other to /tools or to live with less test coverage in autoconf.
I would personally add autoconf to /tools,
Randy McMurchy wrote:
Chris Staub wrote these words on 03/03/06 08:47 CST:
Do you have any opinion on it,
other than to needlessly continue to harp about the "alphabetical" aspect?
Chris, I am trying to be helpful. If I've misunderstood the question,
or even if my lack of knowledge about it
Dan Nicholson wrote:
1. automake depends on autoconf and autoconf test suites depends on
automake. This is circular. The only way to solve it is to add one
or the other to /tools or to live with less test coverage in autoconf.
I would personally add autoconf to /tools, but that's pretty unlik
On 3/3/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>
> Dan, you're asking questions that unless you did these tests yourself,
> you don't fully understand (or know) what all is being lost when you
> say "not as good of test coverage". I know I don't fully understand
> what is being lost. If this
Chris Staub wrote these words on 03/03/06 08:47 CST:
> Do you have any opinion on it,
> other than to needlessly continue to harp about the "alphabetical" aspect?
Chris, I am trying to be helpful. If I've misunderstood the question,
or even if my lack of knowledge about it makes my contribution
Dan Nicholson wrote these words on 03/03/06 08:46 CST:
> Thanks for the reply, but this wasn't exactly what I was looking for.
Okay, I suppose I need to rephrase. How about: I think that whatever
order provides the best test suite coverage is the way to go.
Dan, you're asking questions that unle
Randy McMurchy wrote:
Dan Nicholson wrote these words on 03/03/06 08:25 CST:
My opinion is that it is more important to satisfy as many of the
requisites for the test suites as possible. If that means something
needs to be out of alphabetical order, then so be it.
The whole purpose of this cha
On 3/3/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>
> In fact, keeping it alphabetical, for no other reason that to keep
> it alphabetical, when this breaks (or affords less quality of) test
> suites, is simply wrong. Of course, just IMHO. But that is what you
> were asking for.
Thanks for the
Dan Nicholson wrote these words on 03/03/06 08:25 CST:
> Is anyone else going to comment on the issue of
> libtool/autoconf/automake being used in each other's testsuites, thus
> causing circular dependencies?
>
> Specifically, if libtool is moved up to satifsy autoconf, grep must
> also move wit
Gerard Beekmans wrote:
> Bruce Dubbs wrote:
>> In the LFS cleanfs script, we have the construct:
>>
>> cd /tmp &&
>> find . -xdev -mindepth 1 ! -name lost+found \
>> -delete || failed=1
>>
>> Since I test build a lot of apps in /tmp, this instruction can take a
>> very long time upon bootup
Richard A Downing пишет:
Matthew Burgess wrote:
Richard A Downing wrote:
Jeremy Huntwork wrote:
Nothing *depends* on vim, so
leave it at the end.
I depend on vim. Put it at the front.
Only just :-)
Actually, if we were to replace Vim with Emacs we could have the editor
available early an
Matthew Burgess wrote:
> Richard A Downing wrote:
>> Jeremy Huntwork wrote:
>> Nothing *depends* on vim, so
>>
>>> leave it at the end.
>>
>>
>> I depend on vim. Put it at the front.
>> Only just :-)
>
> Actually, if we were to replace Vim with Emacs we could have the editor
> available early an
Richard A Downing wrote:
Jeremy Huntwork wrote:
Nothing *depends* on vim, so
leave it at the end.
I depend on vim. Put it at the front.
Only just :-)
Actually, if we were to replace Vim with Emacs we could have the editor
available early and retain alphabetical order too. Very much :-)
Jeremy Huntwork wrote:
Nothing *depends* on vim, so
> leave it at the end.
I depend on vim. Put it at the front.
Only just :-)
R.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
49 matches
Mail list logo
