DJ Lucas wrote:
I'm still playing catch up with this. Please go ahead and commit if it
fixes the problems you all are seeing. I see a different problem right
now with /dev/null not being available
That bug was fixed in r7414 by way of a `mknod' command in
chapter06/udev.xml
Regards,
Mat
Jürg Billeter wrote:
Short preliminary report after rebuilding the base system (about 240
packages). Following problems found so far:
Looking very promising! :-)
- iproute2: Uses linux/if.h and linux/ip.h instead of net/if.h and
netinet/ip.h.
- nmap: Uses linux/if.h instead of net/if.h.
Matthew Burgess wrote:
Alexander, if you think that the /lib/udev/bug binary and related rules
are still required I'll add them to the book on the understanding that
it's only a temporary debugging tool and will be removed before release.
Is Archaic's and my own testing enough, or do you think
Matthew Burgess wrote:
Alexander E. Patrakov wrote:
I treat the ticket 1720 as presumably-closed if the bootscript changes
below are implemented, and the udev_update branch can be merged then.
This mail to lfs-dev is only to state this, and ask for discussion if
such discussion is needed (IMH
Chris Staub wrote:
OK, I've got the dependency list done -
http://linuxfromscratch.org/~chris/dependencies.txt. Probably still not
complete, but it's about as close as I'll ever get.
Oh. That's cool. Thanks for all the hard work, Chris! I won't be
around for the next few days, so either t
Matthew Burgess wrote:
> Richard A Downing FBCS CITP wrote:
>> Well, that's that then.
>
> Indeed :-( Thanks to you and George for forwarding the news on.
>
> My own naive take on this is that Jim and co. should aim towards getting
> the santizing script into a state suitable for review on LKML
On Mit, 2006-03-15 at 09:11 +1100, Greg Schafer wrote:
> Jürg Billeter wrote:
>
> > Very short rationale is given on top of each file group. Detailed
> > rationale for each header would unfortunately be too time consuming.
>
> Hmmm, that's not ideal. I'm assuming you've looked at each header and
Jürg Billeter wrote:
> Very short rationale is given on top of each file group. Detailed
> rationale for each header would unfortunately be too time consuming.
Hmmm, that's not ideal. I'm assuming you've looked at each header and used
your judgement to determine whether it should be removed or no
On Die, 2006-03-14 at 13:27 -0800, Jim Gifford wrote:
> Jürg Billeter wrote:
> > On Die, 2006-03-14 at 14:10 +0100, Jürg Billeter wrote:
> >
> > Short preliminary report after rebuilding the base system (about 240
> > packages). Following problems found so far:
> >
> > - dvd+rw-tools: /\b__user/
Jürg Billeter wrote:
On Die, 2006-03-14 at 14:10 +0100, Jürg Billeter wrote:
Short preliminary report after rebuilding the base system (about 240
packages). Following problems found so far:
- dvd+rw-tools: /\b__user/ matched a struct in linux/capability.h whose
name starts with __user. Fixed
On Die, 2006-03-14 at 14:10 +0100, Jürg Billeter wrote:
> * Verify headers with real applications
>Will do a full distro (800 packages) recompilation with these headers
> sometime this week and fix headers resp. applications as necessary
Short preliminary report after rebuilding the base syst
Richard A Downing FBCS CITP wrote:
Well, that's that then.
Indeed :-( Thanks to you and George for forwarding the news on.
My own naive take on this is that Jim and co. should aim towards getting
the santizing script into a state suitable for review on LKML and have
it added to the kernel t
Alexander E. Patrakov wrote:
I treat the ticket 1720 as presumably-closed if the bootscript changes
below are implemented, and the udev_update branch can be merged then.
This mail to lfs-dev is only to state this, and ask for discussion if
such discussion is needed (IMHO, it is not needed).
On Mit, 2006-03-15 at 06:27 +1100, Greg Schafer wrote:
> Jürg Billeter wrote:
>
> > Yes, LLH fails that criteria and it ships with a lot of kernel-only
> > stuff. Based on Jim's script I've written an extended version which
> > removes a lot of headers that shouldn't be part of the linux glibc
> >
Thanks for your comments.
On Die, 2006-03-14 at 13:05 -0500, Bryan Kadzban wrote:
> On Tue, Mar 14, 2006 at 02:10:27PM +0100, J?rg Billeter wrote:
> > a="$(echo -ne '\001')"
> > b="$(echo -ne '\002')"
>
> These can probably be simplified to:
>
> a=$'\001'
> b=$'\002'
Didn't know that, changed.
Jürg Billeter wrote:
> Yes, LLH fails that criteria and it ships with a lot of kernel-only
> stuff. Based on Jim's script I've written an extended version which
> removes a lot of headers that shouldn't be part of the linux glibc
> header set, AFAICT.
Cool. But one has to ask how you arrived at t
On Tue, Mar 14, 2006 at 02:10:27PM +0100, J?rg Billeter wrote:
> a="$(echo -ne '\001')"
> b="$(echo -ne '\002')"
These can probably be simplified to:
a=$'\001'
b=$'\002'
> pushd $KERNEL_PATH/include
I don't think you need to pushd at the start and then popd at the end of
the script. The script
Well, that's that then.
Over to you Jim, mate.
R.
--
Richard A Downing FBCS CITP
http://www.langside.org.uk PGP fingerprint:
D682 49A5 7050 E781 229C A2F0 DE1F C040 DE78 53E8
--- Begin Message ---
LLH hasn't seen a new release for a lot more than six months now and up until
today I hoped to g
LLH hasn't seen a new release for a lot more than six months now and up
until today I hoped to get back on track with new releases. But I've
just spent some time doing a 2.6.14 update, and it came back to me, that
I'd have to spend up to 10 hours just to get a basic 2.6.14.0 ready. And
there'
ck for [us](8|16|32|64) userspace leaks and submit patches
upstream
* Recheck set of installed headers (add missing kernel-only headers to
remove list, remove accidentally added headers from remove list)
* Add support for other architectures
Regards,
Jürg
linux-glibc-headers-20060314
Bryan Kadzban wrote:
> gccver=`gcc -dumpversion`
Oops, that doesn't need to be there anymore...
(I attempted at one point to add -nostdinc to the gcc command line, so I
needed to add the system header location
(/usr/lib/gcc/$MACHTYPE/$gccver/include) to the search path. That
seemed to fail, and
Greg Schafer wrote:
> Bryan Kadzban wrote:
>
>> I've been running Alexander's tests
>> (http://linuxfromscratch.org/pipermail/lfs-dev/2006-March/056159.html)
>>
>
> I agree with Alexander that every userspace header should be
> compilable by itself (at least in an ideal world). Note that curren
22 matches
Mail list logo
