Re: RFC - Raw Kernel Headers

DJ Lucas wrote: Another very minor point is trying to find a way to rip out all the __KERNEL__ portions That's what the "unifdef" tool in FreeBSD does. It also works in Linux. http://www.cs.cmu.edu/~ajw/public/dist/unifdef-1.0.tar.gz Note: Debian uses a CVS version for some reason, need to i

Re: RFC - Raw Kernel Headers

Jim Gifford wrote: I'm only posting this because my results have been positive, and I think the community has a right to see what I've come up with in 18 hours that I've worked on this. Thanks Jim. I'm looking forward to playing with this at the weekend. Andy -- http://linuxfromscratch.org/ma

Re: RFC - Raw Kernel Headers

Alexander E. Patrakov wrote: > DJ Lucas wrote: > >> Another very minor point is trying to find a way to rip out all the >> __KERNEL__ portions > > That's what the "unifdef" tool in FreeBSD does. It also works in Linux. > > http://www.cs.cmu.edu/~ajw/public/dist/unifdef-1.0.tar.gz > > Note: Deb

Re: RFC - Raw Kernel Headers

On Wed, Mar 08, 2006 at 10:23:44PM +1100, Greg Schafer wrote: > Note: this has all been discussed before. eg: > > http://linuxfromscratch.org/pipermail/lfs-dev/2003-October/039740.html > > I still think this whole issue is dangerous territory for non-programmers > and I will not be supporting a

Re: RFC - Raw Kernel Headers

Jim Gifford wrote: A lot of you may have noticed the LLH kernel headers have not been updated as promised. With that in mind, I decided to do some tests over the past few days building LFS and CLFS with raw kernel headers. Unfortunately the raw kernel headers are not enough, but with minor mod

Re: RFC - Raw Kernel Headers

Another very minor point is trying to find a way to rip out all the __KERNEL__ portions That's what the "unifdef" tool in FreeBSD does. It also works in Linux. http://www.cs.cmu.edu/~ajw/public/dist/unifdef-1.0.tar.gz Note: Debian uses a CVS version for some reason, need to investigate. Not

Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

On 3/7/06, Dan Nicholson <[EMAIL PROTECTED]> wrote: > Changes are > relative to the book in > Jeremy's home dir: > > http://www.linuxfromscratch.org/~jhuntwork/lfs-alphabetical/ The build is ICA verified. All tests were run and kernel built with "allyesconfig". Results contain no regressions fro

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

Dan Nicholson wrote: The build is ICA verified. All tests were run and kernel built with "allyesconfig". Results contain no regressions from current LFS SVN except for two GCC test suite failures from applying the patch in http://wiki.linuxfromscratch.org/lfs/ticket/1718. Will probably wait un

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

Jeremy Huntwork wrote: Matt, Gerard, any idea on how/when you want to start looking at merging these changes into trunk? A.S.A.P please, though I'd prefer if you could wait until Chris' dependency stuff was in before merging. I'm going to have to trust yours, Dan's and Chris' hard work and

Re: RFC - Raw Kernel Headers

Based on comments that I have received, I've updated the script. I will start putting in a version # at the top. Thank you all for you comments and suggestions. I really appreciate them. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://lin

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

Jeremy Huntwork wrote: Dan Nicholson wrote: The build is ICA verified. All tests were run and kernel built with "allyesconfig". Results contain no regressions from current LFS SVN except for two GCC test suite failures from applying the patch in http://wiki.linuxfromscratch.org/lfs/ticket/1718

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

Jeremy Huntwork wrote: Matt, Gerard, any idea on how/when you want to start looking at merging these changes into trunk? I'm with Matt on this one and do it sooner rather than later. I do want Chris' dependencies finalized and added to this alphabetical branch so we can implement this in one

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

Matthew Burgess wrote: Jeremy Huntwork wrote: Matt, Gerard, any idea on how/when you want to start looking at merging these changes into trunk? A.S.A.P please, though I'd prefer if you could wait until Chris' dependency stuff was in before merging. I'm going to have to trust yours, Dan's a

Re: RFC - Raw Kernel Headers

Jim Gifford wrote: Based on comments that I have received, I've updated the script. I will start putting in a version # at the top. Thank you all for you comments and suggestions. I really appreciate them. Cool, Jim. Overall, good work. A couple of things: * As the script currently is, it r

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

On 3/8/06, Chris Staub <[EMAIL PROTECTED]> wrote: > > I'm still updating my dependency list here - > http://linuxfromscratch.org/~chris/dependencies.txt > > Unfortunately my network connection died yesterday, and I neglected to > copy this file to my own system (shame on me!) so I couldn't add more

Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch

Στις Τετ 08 Μαρ 2006 03:03, GMT+2, ο/η Dan Nicholson έγραψε: > On 3/7/06, Dan Nicholson <[EMAIL PROTECTED]> wrote: > > On 3/7/06, Dan Nicholson <[EMAIL PROTECTED]> wrote: > > > Good enough for me. The new build order goes: > > > > Oops, forgot about the moved libtool: > > My mind is exploding! Li

Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch

Lefteris Dimitroulakis wrote: I do not know about the iana-etc but for the other packages your build order looks like following the rule : "try to reduce the influence of tools as soon and as much as possible under ch6". This is a very reasonable way of thinking for me specially if it is combin

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

Dan Nicholson wrote: On 3/8/06, Chris Staub <[EMAIL PROTECTED]> wrote: I'm still updating my dependency list here - http://linuxfromscratch.org/~chris/dependencies.txt Unfortunately my network connection died yesterday, and I neglected to copy this file to my own system (shame on me!) so I coul

Re: RFC - Raw Kernel Headers

Actually passive-ftp is now the default. So got that fixed. Also changed the dir so it's not hard-coded. Also added the fixing of s variables, which I found out also need to be converted. New version should be up shortly. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registere

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

On 3/8/06, Chris Staub <[EMAIL PROTECTED]> wrote: > > I think deps. that are needed for testsuites could be labeled as being > "optional" (notice I already started doing that for a few packages) but > you could do the same with several others. For example... I saw that and started making those sam

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

On Wed, 8 Mar 2006 09:10:58 -0800 "Dan Nicholson" <[EMAIL PROTECTED]> wrote: > On 3/8/06, Chris Staub <[EMAIL PROTECTED]> wrote: > > > > I think deps. that are needed for testsuites could be labeled as > > being "optional" (notice I already started doing that for a few > > packages) but you could

Re: `backticks` or $(command) syntax

Dimitry Naldayev wrote: > Bruce Dubbs <[EMAIL PROTECTED]> writes: > >> Randy McMurchy wrote: >> >>> Just for the record, I'll go out on a limb (not really on a limb as >>> I can prove it with real life, actual circumstances) that the >>> $(...) syntax will work in situations where `...` will not.

Re: RFC - Raw Kernel Headers

DJ Lucas wrote: > Jim Gifford wrote: >> This script is >> available at http://ftp.jg555.com/headers/headers. >> >> What I ask from the more advanced members of LFS and CLFS is to give >> them a try, comment on them. Would they be useful to use as a temporary >> alternative. a viable alternative

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

El Miércoles, 8 de Marzo de 2006 18:10, Dan Nicholson escribió: > I saw that and started making those same changes in my sandbox. > However, this could become pretty ugly. Perhaps if there was a > separate Optional Dependencies heading. Or Testing Dependencies. Or, > since LFS doesn't include t

New LFS RElease?

It is time to start considering a new LFS release. I see that we are behind on gcc and glibc as gcc-4.1 and glibc-2.4 have been released. The kernel is about to release 2.6.16 (they have been on 2.6.16-rc5 for about two weeks now) so we are quite a bit behind there. I'm not sure what the status

Re: RFC - Raw Kernel Headers

Thanx Alex and Richard for the pointer on unifdef. Version 00.03 just posted uses unifdef to strip the kernel stuff out. Thanx. The unifdef I used was download from http://www.cs.cmu.edu/~ajw/public/dist/unifdef-1.0.tar.gz -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registe

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

On Wed, Mar 08, 2006 at 07:43:27PM +0100, M.Canales.es wrote: > > Approximate build time: 0.2 SBU > Required disk space: 16.4 MB > Installation depends on: list of build dependencies, like until now > Testsuite depends on: additional dependencies to run the testsuites This looks good, but it wo

Re: New LFS RElease?

Bruce Dubbs wrote: It is time to start considering a new LFS release. I see that we are behind on gcc and glibc as gcc-4.1 and glibc-2.4 have been released. I don't think these are appropriate if we're thinking of a near-term release. They're simply too new and untested at present. The curr

Re: New LFS RElease?

El Miércoles, 8 de Marzo de 2006 20:36, Bruce Dubbs escribió: > It is time to start considering a new LFS release. > > I see that we are behind on gcc and glibc as gcc-4.1 and glibc-2.4 have > been released. > > The kernel is about to release 2.6.16 (they have been on 2.6.16-rc5 for > about two wee

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

El Miércoles, 8 de Marzo de 2006 20:58, Archaic escribió: > > Testsuite depends on: additional dependencies to run the testsuites Of course. That is what 'additional' means ;-) -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.

Re: New LFS RElease?

M.Canales.es wrote: 2- Wait up to can merge both alphabetical and udev_update branchs. That would meant to include also GCC-4.1, Glibc-2.4 and Linux-2.6.16. Why does the merge of the alphabetical and udev_update branches mean that gcc-4.1 and glibc-2.4 would be included as well? -- http://li

Re: New LFS RElease?

El Miércoles, 8 de Marzo de 2006 21:08, Matthew Burgess escribió: > Why does the merge of the alphabetical and udev_update branches mean > that gcc-4.1 and glibc-2.4 would be included as well? Would meant that depending on how many time will take to us to do the merges and how behind latest avai

Re: New LFS RElease?

On Wed, Mar 08, 2006 at 01:36:37PM -0600, Bruce Dubbs wrote: > It is time to start considering a new LFS release. Not yet, IMO. We have 3 branches, 2 in a state of flux. If we go with trunk or alpha we release with a really old kernel with security vulnerabilities. udev_update is really the only b

Re: Alphabetical Build Clean [Was Re: [Alphabetical] Build order, Bug 684, Issue with Bash patch]

On Wed, Mar 08, 2006 at 09:00:35PM +0100, M.Canales.es wrote: > > Of course. That is what 'additional' means ;-) Sometimes people (especially me) need an extra level of pedanticness to avoid ambiguity. ;) -- Archaic Want control, education, and security from your operating system? Hardened Lin

Re: RFC - Raw Kernel Headers

Jim Gifford wrote: Thanx Alex and Richard for the pointer on unifdef. Version 00.03 just posted uses unifdef to strip the kernel stuff out. Thanx. The unifdef I used was download from http://www.cs.cmu.edu/~ajw/public/dist/unifdef-1.0.tar.gz The email Greg refered to earlier mentioned http:/

Re: RFC - Raw Kernel Headers

On 3/7/06, Jim Gifford <[EMAIL PROTECTED]> wrote: > A lot of you may have noticed the LLH kernel headers have not been > updated as promised. With that in mind, I decided to do some tests over > the past few days building LFS and CLFS with raw kernel headers. > Unfortunately the raw kernel headers

Re: RFC - Raw Kernel Headers

Gerard, the one that Greg mentions wouldn't compile for me, and plus the one I use is a package instead of individual files. Either one will work. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-de

Re: RFC - Raw Kernel Headers

Tushar Teredesai wrote: > Gentoo is using a script similar to the above script to sanitize the > headers. Do you have a pointer? Thanks. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See

Re: RFC - Raw Kernel Headers

On 3/8/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > Tushar Teredesai wrote: > > > Gentoo is using a script similar to the above script to sanitize the > > headers. > > Do you have a pointer? Thanks. > The kernel-2.eclass file at has

Re: RFC - Raw Kernel Headers

Tushar Teredesai wrote: BTW, instead of writing to /tmp/new_header file, the script should probably write to $header.orig. The file in /tmp may exist and may not be owned by the user running the script. Will be done in the next version, expect it shortly. Also since this is starting to beco

Re: RFC - Raw Kernel Headers

Tushar Teredesai wrote: > The kernel-2.eclass file at > has > the gory details on how gentoo creates the headers. It has lot of > extra functions since the same elcass is also used for kernel > compilation. Ok, thanks. Tho' I had man

Re: List of package urls

Matthew Burgess <[EMAIL PROTECTED]> writes: > Randy McMurchy wrote: > >> Why is it that the package URL is not listed, but only the location >> where it *should* be? >> > >> So, why not just list the package URL? > > Short answer...it's a historical oversight, I think. > > Long answer... > > We u

Finding a new leader for the LFS Bootscripts

I am finding that I have no time to work on the lfs bootscripts these last few months, but at the moment I think I am the leader who decides what gets added or not.These days, I am barely even reading my email. Anyone else willing to take the leadership role for the bootscripts?-- Nathan Coulson (c

Re: RFC - Raw Kernel Headers

Just playing the devil's advocate but have you run your script against a 2.6.12 kernel and compared your output to the 'official' 2.6.12 llh files. Jim Gifford wrote: Tushar Teredesai wrote: BTW, instead of writing to /tmp/new_header file, the script should probably write to $header.orig. T

Re: RFC - Raw Kernel Headers

George Boudreau wrote: Just playing the devil's advocate but have you run your script against a 2.6.12 kernel and compared your output to the 'official' 2.6.12 llh files. Jim Gifford wrote: Tushar Teredesai wrote: BTW, instead of writing to /tmp/new_header file, the script should probabl

Re: RFC - Raw Kernel Headers

Greg, I'm just working on that right now, first I wanted to see if it was possible. I will be adding what I know to the mix in the next couple of hours. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/list

Re: RFC - Raw Kernel Headers

Updated version with the links and why I did things is up. The only thing that has been questionable and I'm still trying to research is the __iomem removal. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/lis

Re: RFC - Raw Kernel Headers

Jim Gifford wrote: Updated version with the links and why I did things is up. The only thing that has been questionable and I'm still trying to research is the __iomem removal. __iomem removal is not questionable at all. This macro indicates that this is not a valid pointer that you can deref

Re: RFC - Raw Kernel Headers

On 3/8/06, Greg Schafer <[EMAIL PROTECTED]> wrote: > > Grrr, Gentoo is a convoluted mess.. That's why we have LFS:-) BTW, if you need some rudimentary scripts to make navigating thru the files easier, check out distro-tools at . I have an updated ver

Re: New LFS RElease?

Bruce Dubbs wrote: It is time to start considering a new LFS release. Only after reverting all UTF-8 changes in trunk. BLFS as-is is not ready, and BLFS+Wiki is not BLFS. And even BLFS+Wiki will take at least three months before I can put it into shape. Matthew: sorry for violating my promis

Re: RFC - Raw Kernel Headers

Alexander E. Patrakov wrote: > __iomem removal is not questionable at all. This macro indicates that > this is not a valid pointer that you can dereference directly, but a > cookie that you can pass to the ioremap() in-kernel function in order to > access the hardware via the MMIO mechanism. Th

Re: RFC - Raw Kernel Headers

Thanx Greg, Fixed. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page

Re: New LFS RElease?

Archaic wrote: > What's the hurry? Who are we competing with? I'm not trying to be > defensive, but trying to sort out your reasoning. We all want a release, > but that should have happened a few months back. It just isn't ready > right now and a rush job is not a good idea. No real hurry. I jus

Re: Finding a new leader for the LFS Bootscripts

Nathan Coulson wrote: I am finding that I have no time to work on the lfs bootscripts these last few months, but at the moment I think I am the leader who decides what gets added or not. These days, I am barely even reading my email. Sorry to see you go, but if you don't have the time, you

Re: RFC - Raw Kernel Headers

Greg Schafer wrote: > But that doesn't escape the fact that this "every man for himself" > approach is essentially wrong. Yes it's been talked about for years, but > Linux *needs* a centralized linux headers project of some sort. Llh is a > step in the right direction and IMHO there is still plent

Re: RFC - Raw Kernel Headers

DJ Lucas wrote: George Boudreau wrote: Just playing the devil's advocate but have you run your script against a 2.6.12 kernel and compared your output to the 'official' 2.6.12 llh files. There is still a little more to do. unifdef will leave quite a few empty files...well, empty cept f

Re: RFC - Raw Kernel Headers

Sorry if this message arrives twice... Jim Gifford wrote: I'm only posting this because my results have been positive, and I think the community has a right to see what I've come up with in 18 hours that I've worked on this. Jim, I'm seeing some diffs that concern me with 0.6 version o

Re: RFC - Raw Kernel Headers

DJ Lucas wrote: Jim, I'm seeing some diffs that concern me with 0.6 version of the script when comparing to LLH. Also, I had a lot of .orig files left in the output tree which probably partially explains the second example below. Fixed - I had the rm $header.orig in the wrong place. There are