On 7/25/05, Randy McMurchy [EMAIL PROTECTED] wrote:
Tushar Teredesai wrote these words on 07/25/05 01:37 CST:
My aplogies for that Randy. As I explained in my private e-mail (to
Randy), I was under the impression I was replying to a technical
discussion and the comment about Zack did not
TheOldFellow wrote:
But the point is that without Jim's efforts there would not be a
Cross-LFS branch. To a large degree it's 'Jim's Branch'. (Ryan's
ideas, maybe some from Greg too, but Jim actually (mostly) did the branch.)
-snip-
So in my view: Use IRC for branch development UP TO the
On 7/25/05, Tushar Teredesai [EMAIL PROTECTED] wrote:
On 7/22/05, Henrik S. Hansen [EMAIL PROTECTED] wrote:
Robert Connolly [EMAIL PROTECTED] writes:
I think everyone would agree that patches have the same copyright as
the files that they patch, with exception to new files, and unless
Tushar Teredesai [EMAIL PROTECTED] writes:
I had assumed 1. But you all are correct, it is better to mark it
so. Will do that.
Thank you. :-)
As a followup, not all patches need a license notice. Insignificant
changes are not copyrightable, so the patches that simply change a few
symbols or
Randy McMurchy wrote:
For example, I reported a day or two ago that the book still contains
the groups program being installed by the Shadow program. Not even a
mention from anyone about this.
That's a little harsh, I feel. We're *all* volunteers here Randy. Your
email suggests you
A number of people have emailed me privately, and its also come up on
the list recently, so here's my thoughts on what could/should be going
on in LFS land. Yes, I know it's taken me far too long to ditch my
Release Manager hat and don my Project Manager/Planner hat, but still..
LFS-6.2:
On 7/25/05, Bruce Dubbs [EMAIL PROTECTED] wrote:
Matthew Burgess wrote:
Now, here's the biggy. The jury's still out on this one :) I'd like to
see GCC-4.x in this one, but that's dependent on the stability of said
compiler with the rest of the toolchain (Glibc in particular) and its
Bruce Dubbs wrote:
My only suggestion here is to not combine cross build techniques and
gcc-4. IMO it would be better to tackle these large changes one at a
time. Perhaps a LFS 6.3 with gcc-4 would be appropriate.
Right, it all depends of course on whether folks want things to be
On Mon, Jul 25, 2005 at 09:15:45PM +0100, Matthew Burgess wrote:
That said, there's nothing stopping us from releasing a 7.0 that happens
to contain cross build techniques and gcc-4, it's just it'll no doubt
take us much longer to reach a releasable state.
And there is nothing requiring an
On Mon, 25 Jul 2005, Matthew Burgess wrote:
LFS-6.2:
This will just be an incremental release, further stabilising our
already proven PLFS-based build method. GCC-3.4.x combined with
Glibc-2.3.5 seems pretty robust, and adding binutils-2.16.1 to the mix
should further solidify that.
Archaic wrote:
And there is nothing requiring an imminent release of cross-lfs, either.
The idea of getting gcc-4 into trunk post 6.2 sounds good. What really
sounds good after that is an i18n cleanup in 6.4 and a merge to
cross-lfs when it is done. That said, there is also no technical reason
Matthew Burgess wrote:
snip
LFS-7.0:
Now, here's the biggy. The jury's still out on this one :) I'd like to
see GCC-4.x in this one, but that's dependent on the stability of said
compiler with the rest of the toolchain (Glibc in particular) and its
effect on BLFS packages.
+1 on GCC 4.x
Greg Schafer writes:
Jim, I don't know how to say this without sounding offensive, so please
accept my apologies in advance if I'm totally off the planet, but quite
frankly, I don't believe you have the necessary know-how to be making
fundamental changes to the cross build method.
I've
On Mon, 25 Jul 2005, GN wrote:
On Monday 25 July 2005 12:36, Matthew Burgess wrote:
A number of people have emailed me privately, and its also come up
on the list recently, so here's my thoughts on what could/should be
going on in LFS land. Yes, I know it's taken me far too long to
Jim Gifford wrote:
I've been working on this for over a year Greg, you a few weeks.
A few months actually. And in those few months I've managed to come up
with a sane cross build method... something that the punters should
hopefully be able to understand. Many folks here have said they do not
Greg Schafer wrote:
Jim, the evidence is clear. Please, I urge you to do the ethical thing and
acknowledge you have used my research.
What evidence? Please note, in this email I am not countering the actual
claim that you have discovered first the issues that Jim fixed changed in
Cross-LFS.
Greg Schafer wrote:
For the record, here is what Jim changed:
Examples please? Just showing us vague changelog messages and saying
you researched that is not very convincing. I also think it would be
fair to hold off on the accusations until Jim is back from vacation so
that he may
On Monday 25 July 2005 16:40, Ken Moffat wrote:
[...]
kernel 2.6.12 would be nice.
Given timescales, I imagine 2.6.13 will be out. But seriously,
what do you see in 2.6.12 that isn't there in 2.6.11 ?
Mostly bug fixes. 2.6.12 is stable now, 2.6.13 might be 'bleeding
edge'. IMHO.
GN wrote:
Incorporate Wifi. I know this can be tricky, but one can only
wish.
[...]
Well, if that's not BLFS, I don't know what is ;)
Almost all notebooks come with Wifi nowadays. I see it as part of the
core in any distribution. Again, IMHO..
SeattleGaucho
My laptop has WiFi, and I
On Monday 25 July 2005 18:14, Ken Moffat wrote:
[...]
Personally, I bleed on 2.6.12 (my athlon64's ability to power off
seems to have been broken by the acpi changes). But, most of the
important bug fixes in 2.6.12 should be in 2.6.11.12, no ?
I am running 2.6.12 in a couple of PCs with no
On Wed, 2005-07-20 at 09:15 +0200, Jens Olav Nygaard wrote:
Since the subject became increasingly inaccurate, and since my
rate of hickups to installed packages indicates that this will
not be my last question, I swap in another thread...
Now reading the book more carefully, I notice that
Jeremy Huntwork wrote:
though I would like to have one point clarified, please. I've heard it
said before that major version numbers in LFS were supposed to represent
In the past the LFS major version number was increased when a major
package in LFS had a major release. For instance, going
Matthew Burgess wrote:
Additionally, of course, cross-lfs is to be
seriously considered at this point. I've not looked at Jim, Ryan,
Opinions seem divided on this one. Should cross-lfs become part of the
mainstream book? In other words, will every LFS'er be building according
to the
TheOldFellow wrote:
Matthew Burgess wrote:
I also wanted to get some internationalisation work sorted out for LFS,
as I have to admit to being somewhat embarassed seeing all the
disclaimers dotted around the book stating that things don't work right
in multibyte locales. However, it looks like
Gerard Beekmans wrote:
[...]
This way I believe we'll have the best of both world.
Or we can make separate book volumes. Is that possible with Docbook?
--
Anderson Lizardo
[EMAIL PROTECTED]
http://www.linuxfromscratch.org/
signature.asc
Description: OpenPGP digital signature
--
Hi
Following on from recent goodwill discussions with Matt, here is another
issue I'm bringing here for your attention.
The Grub page in LFS says this:
Note that the test results will always show the error ufs2_stage1_5 is too
big. This is due to a compiler issue, but can be ignored unless you
Ryan Oliver wrote:
...
Strange. I realized now that there seems to be a serious time
lag somewhere. Your message just arrived in my mail box, while
I see it's dated 050721... Oh, well.
J.O.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Greg Schafer wrote:
Hi
I haven't seen this mentioned on the LFS lists so I'm bringing it up here
for your info.. LFS is certainly affected.
2.6.12 kernel introduced a new feature called address space randomization
and it's switched on by default. AFAICT, this is the same thing that Red
Gerard Beekmans wrote:
...
mainstream book? In other words, will every LFS'er be building according
to the cross-lfs (toolchain) methodology even if they don't require it?
...
My prediction is that everybody using i?86 in the near future will
be wanting x86_64 or emt64 (right name?) as all
29 matches
Mail list logo
