Anderson Lizardo wrote:
TheOldFellow wrote:
Matthew Burgess wrote:
I also wanted to get some internationalisation work sorted out for LFS,
so where are the non-8bit-language (indeed, apart from Manuel and Alex,
where are the non-ASCII) volunteers to test this? It's all very well to
Hey,
On Die, 2005-07-26 at 09:52 +1000, Greg Schafer wrote:
For the record, here is what Jim changed:
[...] snipped the evidence list
For the record, all of my cross research is available via mailing list
postings and scripts on the DIY website. It's there for anyone to see. The
anti-LFS sentiments
On Mon, 2005-07-25 at 00:24 -0500, Tushar Teredesai wrote:
SNIP
That said, for a by-the-book LFS + BLFS installation it doesn't make
much sense to have multiple directories since there is only one
version of automake installed. That is the reason I symlink them on my
system.
Heh, same here,
El Martes, 26 de Julio de 2005 04:16, Gerard Beekmans escribió:
Clutter will be a concern. The TOC has to be clean and easy to navigate.
Like I said above, a chapter re-organization may be required to maintain
a logically flowing TOC where you don't get lost.
Actually at this momment we are
On Tue, 26 Jul 2005, TheOldFellow wrote:
OK, we have some i18n 8-bit users, but multibyte? I see some names than
might be Chinese on the list occasionally.
I imagine some of our german-speaking users might prefer to use utf. I
often see posts (not necessarily on lfs lists) where there are
TheOldFellow wrote:
Anderson Lizardo wrote:
TheOldFellow wrote:
Matthew Burgess wrote:
I also wanted to get some internationalisation work sorted out for LFS,
so where are the non-8bit-language (indeed, apart from Manuel and Alex,
where are the non-ASCII) volunteers to test this?
I've definitely got a strangeness in my current build scripts for
pure64 x86_64 from i686. First time I built it, running make check on
target glibc hung in inet tests. Looking at it, I discovered I had
omitted the fix_test patch. Applied that, tests completed.
This time, I'm trying to get
On Tue, 2005-07-26 at 13:31 +0100, Ken Moffat wrote:
I've definitely got a strangeness in my current build scripts for
pure64 x86_64 from i686. First time I built it, running make check on
target glibc hung in inet tests. Looking at it, I discovered I had
omitted the fix_test patch.
On Tue, 26 Jul 2005, Ryan Oliver wrote:
Indeed I have seen this a couple of times...
From (possibly faulty) memory I recall noticing it in chroot builds
(which for convenience is predominately what I have done of late...)
will check my logs and get back to you...
Thanks, I'll appreciate
Following my house move, and change of ISP, my LFS documents:
LFS-References
Essential Pre-reading for LFS
How to convert LFS to use runit instead of SysVinit
are back on-line in my new domain.
http://www.langside.org.uk/lfsdocs
Richard.
--
Hi all,
Just a topic which really doesn't need discussion on this list, however,
one item is worth mention (question to Bruce).
I just updated Anduin with the new CrackLib files. I find it interesting
how much better (and, of course, faster) Gzip compresses text files than
Bzip.
The CrackLib
Randy McMurchy wrote:
Hi all,
Just a topic which really doesn't need discussion on this list, however,
one item is worth mention (question to Bruce).
I just updated Anduin with the new CrackLib files. I find it interesting
how much better (and, of course, faster) Gzip compresses text
Hi all,
This problem still exists in svn-20050725. Could someone please comment on David's solution and may be fix the book?
LaurensOn 7/8/05, David Fix [EMAIL PROTECTED] wrote:
Hi guys, I wasn't sure which list to post this to, so I posted it to bothBLFS support and BLFS Development...I'm using
Alexander E. Patrakov wrote:
Archaic wrote:
Has this been sent upstream?
Probably, by Debian. That's where I got the fix from.
Has anyone else managed to find any archives of the bug-gawk mailing
list, which is where bug reports are supposed to be sent. At least
that's what README in the
Guys,
I just talked to Jim a bit ago to try and clear up the issues as of late
surrounding cross-lfs, what the status in general is, etc.
First off let me start to clarify that cross-lfs is not made part of LFS
officially in that it is integrated with the book and goes through the
regular
Gerard Beekmans wrote these words on 07/26/05 16:57 CST:
For all intents and purposes it might as well be running on Jim's
private machines while it is being developed and turned into something
usable that can be integrated with the LFS Book.
When Cross-LFS gets to a point it becomes an
Randy McMurchy wrote:
However, if there is a chance that the Cross-LFS stuff
can/will/should/might be/whatever the official LFS product, then
folks should be able to discuss things and recommend/suggest changes,
starting now.
I can see your point - public interest, ideas and discussion often
Gerard Beekmans wrote these words on 07/26/05 17:33 CST:
[snip good stuff]
If we want this list to return to what
it used to be, we first need to brush up on our inter-personal skills.
The rest will automatically follow.
Well said. And I, as much as anyone, need to follow the above
Jeremy Huntwork wrote:
What evidence?
Surely I don't need to point out how easy it is to determine who is
accessing what and when and where from, using apache logs, ip addresses,
dns, etc etc etc?
Secondly you say that you made those changes in the diy cross build as a
result of your
Okay all, let's just drop this right here and now please.
I don't want to see another (flame) war start here. Jim said he looked
at your work Greg, but he didn't use it. That looking at your work bit
may account for some/most of the log entries you have been seeing.
The coincidental timing
Justin R. Knierim wrote:
Examples please? Just showing us vague changelog messages and saying
you researched that is not very convincing.
Justin, with all due respect, and this is not directed specifically at
you, but it appears there is still a tendency within LFS for folks to jump
into
DJ Lucas wrote:
Well it looks easy enough to fix. Is it as simple as I think it
isreplacing the fopen to point at the different filename...better if
the open call to exec-shield-randomize fails, then go for
randomize_va_space...assuming the data contained in each is the same.
Or check
On Tue, Jul 26, 2005 at 06:12:18PM -0600, Gerard Beekmans wrote:
The logs can be improved somewhat, especially the part where syslogd and
klogd are stopped and restarted after rotation, rather than simply
reloading it after it. That should work too.
Gerard, FWIW sysklogd never needs
Ryan Oliver wrote:
Now a few comments after reading this thread...
1) I support what Jim has done (though I haven't had time to test it),
anything that removes a pile of builds is a good thing for lfs.
Excellent.
2) Please all, enough with the attitude. We are all working towards the
same
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
Archaic wrote:
Has this been sent upstream?
Probably, by Debian. That's where I got the fix from.
Has anyone else managed to find any archives of the bug-gawk mailing
list, which is where bug reports are supposed to be sent. At
Randy McMurchy wrote:
That said, I have always respected your ideas, though often I've
thought your delivery was less-than-stellar.
Like it or lump it :-)
You made a recent post
which said that Jim's latest mass-change had some technical issues,
but you didn't discuss the reasons why you
Greg Schafer wrote these words on 07/26/05 22:46 CST:
Glibc Headers
[snip highly technical and best as I can figure, well-reasoned analysis]
Thanks, Greg. I am interested in hearing from the pro-remove-headers
folks in response to your message.
Hopefully, there will be continued discussion.
27 matches
Mail list logo
