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
ca
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 fe
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 it
[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 sugges
(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 neve
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
b.) work with Jim's methods of sanitizing our own headers
c.) Look at what
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 d
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 test
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; use
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 te
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
Matt Darcy wrote:
Hi all,
Now I've laid down my request lets look at the topics, that in my mind
are unclear and up for dicussion.
2.) Udev - This again has been a hot topic of many projects, but with
LFS now dropping hotplug I feel it important ti discuss and clear up a
few areas
a.) Ude
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 g
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 defi
> 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 jus
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 definition
(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
On 5/1/06, Bryan Kadzban <[EMAIL PROTECTED]> wrote:
a setup. The sticking point would be programs that include linux/.h
or asm/.h, if there are any. And it sounds like there are glibc
alternatives to all of those headers anyway, so it would be the program
that's broken. (Unless it's Linux-s
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 performed
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 lik
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 appea
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 ad
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 leng
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.
Readjusting
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 mention
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
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
http://www.linuxfromscratch.or
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. Bein
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 th
On Sun, Apr 30, 2006 at 10:23:10PM -0400, Jeremy Huntwork wrote:
>
> I still need to go over it a few more times before I understand some of
> the intricacies of what's happening there.
Sounds good. I'd like to read what you come up with as I don't know,
either.
--
Archaic
Want control, educa
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 indecisive
On Sun, Apr 30, 2006 at 10:32:50PM -0400, Jeremy Huntwork wrote:
>
> I'm sure we could do the XInclude on the majority of text and commands
> for that section, but in the two instances where the output differs,
> just plug in the output for that specific section. Which page would
> hold the so
41 matches
Mail list logo
