On 4/29/06, Jim Gifford [EMAIL PROTECTED] wrote:
What would be nice is if we could go back to the 2.4 does things,
they we wouldn't have these issues. I've contacted David, to see if we
could collaborate on the effort, but I haven't heard anything yet. From
what I've read in that thread,
Ioan Ionita wrote:
Probably not gonna be merged. Linus doesn't plan on making any header
useable by userspace. I don't quite understand his whole point. It
seems like he's allergic or something, thinking that if the headers
are cleaned up, apps will start using them. Anyway, he doesn't seem to
Hi all,
First of all, I have sent this mail to all lists, but I'd request that
all responses happen on LFS-DEV to keep this thread (assuming it gets
response) together and followable.
Reading through threads in general there appears to be a little
seperation and difference of opinion on a
Matt Darcy (the guvnah!) wrote:
1.) Kernel Headers, yes you knew this was coming but its certainly worth
talking about, a lots been said on this but its really still unclear of
direction. I suppose the discussion should center around
a.) Do we stick with LLH and pray it takes off again
b.)
[EMAIL PROTECTED] wrote:
Matt Darcy (the guvnah!) wrote:
1.) Kernel Headers, yes you knew this was coming but its certainly worth
talking about, a lots been said on this but its really still unclear of
direction. I suppose the discussion should center around
a.) Do we stick with LLH and pray
[EMAIL PROTECTED] wrote:
Matt Darcy (the guvnah!) wrote:
c.) what are the livecd doing with udev - removing hotplug ? what rules
are they using ? etc
I'd hope they're using the same rules as LFS+BLFS.
Our rules contain all official ones, plus some livecd-specific ones.
If not, I'd
(Resending because I think I used the wrong From: address last time
around.)
Andrew Benton wrote:
install the raw kernel headers from the 2.6.16 kernel in
/tools/glibc-kernheaders and compile glibc against them. For
userspace, keep using the 2.6.12 sanitised llc headers. Works for me.
It
Ioan Ionita wrote:
Linus doesn't plan on making any header useable by userspace.
Not entirely true; from what I was reading in the archives, Linus
doesn't mind making the kernel headers usable by glibc. But he
absolutely does not want random userspace programs using them, because
they will
I wrote:
III) Devices usable in LFS are correctly named and have proper
permissions, as assigned by LFS developers.
III) II, plus: Devices not usable without BLFS packages are at least
correctly named. IOW, if one installs a BLFS package without reading the
udev/passwd part in BLFS book, the
Bryan Kadzban wrote:
Andrew Benton wrote:
install the raw kernel headers from the 2.6.16 kernel in
/tools/glibc-kernheaders and compile glibc against them. For
userspace, keep using the 2.6.12 sanitised llc headers. Works for me.
It worked well for LFS-6.0. It's a tried and tested method
Bryan Kadzban wrote:
(Resending because I think I used the wrong From: address last time
around.)
Andrew Benton wrote:
How will your non-glibc userspace packages use inotify?
Yes, glibc has support for its syscalls, but the LLH headers do not, and
AFAIK glibc doesn't install headers for it;
On Sat, Apr 29, 2006 at 01:59:47PM -0500, Bruce Dubbs wrote:
Except for some touch ups by Manuel, there have been no commits to LFS
for two weeks. Has everyone else lost their availability at the same time?
I thought we were very close to releasing LFS-6.2-testing.
Close is a relative term.
On Sun, Apr 30, 2006 at 09:29:16AM +0100, Matt Darcy wrote:
1.) Kernel Headers, yes you knew this was coming but its certainly worth
talking about, a lots been said on this but its really still unclear of
direction. I suppose the discussion should center around
For LFS-6.2, I recommend
Joe Ciccone wrote:
Bryan Kadzban wrote:
How will your non-glibc userspace packages use inotify?
I'm unaware of what glibc-2.3.6 does. glibc-2.4 does install
/usr/include/sys/inotify.h regardless of whether linux/inotify.h is
found.
Ah, so glibc does install it.
So then, if glibc
Chris Staub wrote:
Matt Darcy wrote:
3.) users and group creation, I'm reluctant to touch on this again as
I know its close to a few individuals hearts and a lot of time has
been put into this, but due to the ude discussion I think its worth at
least touching upon.
a.) do we define
Bryan Kadzban wrote:
So then, if glibc installs everything like this, why do we need any
kernel headers at all? Is it just for glibc (and stuff like util-linux
that's Linux specific)? Hmm.
Yes, LKML folks appear to agree that the kernel headers are just for the C
library (be it glibc,
[EMAIL PROTECTED] wrote:
Bryan Kadzban wrote:
So then, if glibc installs everything like this, why do we need any
kernel headers at all? Is it just for glibc (and stuff like util-linux
that's Linux specific)? Hmm.
Yes, LKML folks appear to agree that the kernel headers are just for the C
Andrejs Spunitis wrote:
/mnt/src/texinfo-4.8/info/terminal.c:236: undefined reference to `tgoto'
/mnt/src/texinfo-4.8/info/terminal.c:236: undefined reference to `tputs'
Support questions should be directed to the lfs-support list.
The symbols tgoto and tputs are from ncurses. You might want
Bruce Dubbs wrote:
I'm not sure I completely understand. Is Linus saying that it is up
to the interface library to *copy* the needed data structures (not
including) from the kernel to their own set of public headers?
Yes.
If so, is this because the kernel devs don't know what definitions
(Gaah! I think I need to change the address that I've subscribed. At
least that way my mailer would use the right one by default.)
[EMAIL PROTECTED] wrote:
Bryan Kadzban wrote:
So then, if glibc installs everything like this, why do we need any
kernel headers at all? Is it just for glibc
steve crosby wrote:
iptables is one such application - currently non functional with
jim's script created headers, but have yet to identify why.
I thought iptables required the raw kernel source anyway?
Regardless, it's definitely one of the few Linux-specific programs. Its
only purpose in
Hey All,
Trying to close this ticket:
http://wiki.linuxfromscratch.org/lfs/ticket/1768
In trying to incorporate Dan's suggestions, I decided to *require* the
sanity check at the end of chapter 6 gcc. Up to now the wording there
has said it was recommended to repeat the sanity checks
Jeremy Huntwork wrote these words on 04/30/06 18:48 CST:
That always kind of bugged me - that in the middle of the flow you have
to go *back* in the book and repeat some instructions.
You must do this in two other spots in the book and it has always
bugged me as well. I remember not too long
Randy McMurchy wrote:
[snip]
Anyway, as long as you're trying to remove confusion, I'd like to see
th mention of going *back* to GCC Pass1 in the GCC Pass2 instructions
to just include the instructions again instead of saying to go back
to the Pass1 instructions.
And, more importantly, I'd
On 4/30/06, Bryan Kadzban [EMAIL PROTECTED] wrote:
(That's because fcntl.h is glibc's interface to the rest of userspace.
It needs to define that interface well enough that random userspace
programs will almost all work. In the same vein, though, the Linux
kernel needs to define its interface
Jeremy Huntwork wrote:
Please comment on the following:
http://linuxfromscratch.org/~jhuntwork/html-lfs-trunk/chapter06/readjusting.html
and
http://linuxfromscratch.org/~jhuntwork/html-lfs-trunk/chapter06/gcc.html
I agree with Randy's comments, but would like to address the appearance.
On Sun, Apr 30, 2006 at 08:12:18PM -0400, Jeremy Huntwork wrote:
Agreed. Unless someone else raises an objection, I'll take a look at
fixing that up.
There might be a better way to go about this. With only one exception,
the test commands are identical. So the first question is, why not add
Archaic wrote:
There might be a better way to go about this. With only one exception,
the test commands are identical. So the first question is, why not add
grep 'SEARCH.*/usr/lib' dummy.log
I answered this already. See below.
[snip]
Now we have identical tests and manageable output
Bruce Dubbs wrote:
I don't like all the instructions in the caution. If it is supposed to
be mainline, then put it mainline, not in a caution block. If you
really need the caution, just say that the following instructions are
considered mandatory and then drop back to the normal presentation.
Archaic wrote:
Of course, the only reason for XIncludes is that despite the best
intentions, it is likely a change to one page will be forgotten about in
the other.
Also, keep in mind that the location of the startfiles likewise differs
when running the tests at those two points.
On Sun, Apr 30, 2006 at 10:00:09PM -0400, Jeremy Huntwork wrote:
Also, keep in mind that the location of the startfiles likewise differs
when running the tests at those two points.
Yes, as I pointed out. I made an assumption on the SEARCH grep since I
didn't know, but I explicitely mentioned
On Sun, Apr 30, 2006 at 09:55:25PM -0400, Jeremy Huntwork wrote:
As I already said, I didn't include it on the readjusting page because I
didn't want to confuse the reader with perhaps unexpected occurrences of
'/tools'.
Unexpected? Please explain. /tools should either be in the output or
And don't overlook the changes to the 2 greps. Regardless of anything
else this thread produces, those changes must be made to fix the current
wrapping problem.
--
Archaic
Want control, education, and security from your operating system?
Hardened Linux From Scratch
Archaic wrote:
And don't overlook the changes to the 2 greps. Regardless of anything
else this thread produces, those changes must be made to fix the current
wrapping problem.
Yes, thanks. I thought of doing something like what you suggested, but
wasn't sure if it was really appropriate.
On Sun, Apr 30, 2006 at 10:12:50PM -0400, Jeremy Huntwork wrote:
Personally, I would prefer another solution.
Drop the 2nd instance of the crt tests and drop the SEARCH tests.
Otherwise, the output must be wrestled into conforming to layout
requirements.
--
Archaic
Want control, education,
Archaic wrote:
On Sun, Apr 30, 2006 at 09:55:25PM -0400, Jeremy Huntwork wrote:
As I already said, I didn't include it on the readjusting page because I
didn't want to confuse the reader with perhaps unexpected occurrences of
'/tools'.
Unexpected? Please explain. /tools should either be in
Archaic wrote:
On Sun, Apr 30, 2006 at 10:12:50PM -0400, Jeremy Huntwork wrote:
Personally, I would prefer another solution.
Drop the 2nd instance of the crt tests and drop the SEARCH tests.
Otherwise, the output must be wrestled into conforming to layout
requirements.
Sorry to be
37 matches
Mail list logo
