On Thursday 21 September 2006 00:41, Bryan Kadzban wrote:
> Bryan Kadzban wrote:
> > Done in r7793.
>
> And, after looking at the udev-100 bug, it appears that I missed one.
> All the ENV{PHYSDEV*} variables are deprecated; the ENV{PHYSDEVBUS}
> that almost everyone uses in 05-udev-early.rules (to
On Mon, Sep 25, 2006 at 04:24:52PM +0100, Alex Merry wrote:
> According to Kay on the linux-hotplug-devel list, ENV{PHYSDEVBUS} should
> still be used in 05-udev-early.rules (as per the etc/rules.d directory
> of udev-100). Apparently it doesn't raise a warning when used with
> WAIT_FOR_SYSFS,
Hi folks,
Just wondering what the preferred approach would be for upgrading Linux
to the latest version (2.6.18 at the time of writing)? Previously,
we've just upgraded the kernel regardless of the headers it wants
installed because of having the linux-libc-headers around, which we
could pat
> Personally, I think this should be tackled in a 2-step approach. 1)
> Simple version bump to 2.6.18. 2) Drop linux-libc-headers installation,
> replacing it with 'make headers_install' from the kernel tarball. That
> way, if the headers_install thing is not feasible for the time being, we
> do
Matthew Burgess wrote:
Hi folks,
Incidentally, has anyone done any work on getting the headers_install
approach integrated with jhalfs. Is any specific support required, or
does it just require the "linux-libc-headers" page being replaced with a
"linux headers" page?
yes.. changing the
On 9/25/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
For jhalfs, first we must to make mandatory the linux kernel package download
(at this moment the kernel download/build is optional to allow folks to
upgrade their kernel sources using patches). Then we will need to map the new
headers page sc
Guys,
Using make headers_install will work for x86 and x86_64, but there
are a lot of issues and going to be a lot of breakage with BLFS. So I
hate to say this, but CLFS will be remaining with our linux-headers
package. Just as an FYI, Slackware, Slamd64, and others have adopted the
CLFS pa
Jim Gifford wrote:
Guys,
Using make headers_install will work for x86 and x86_64, but there
are a lot of issues and going to be a lot of breakage with BLFS. So I
hate to say this, but CLFS will be remaining with our linux-headers
package. Just as an FYI, Slackware, Slamd64, and others have
Jim Gifford wrote:
the bottom line is that there will be some major breakages from the
headers_install, are you ready to tackle those?
As Dan and I (at least) have previously stated, yes, we're prepared to
tackle any BLFS breakage (others are welcome to help out too).
Regards,
Matt.
--
ht
El Lunes, 25 de Septiembre de 2006 21:39, Dan Nicholson escribió:
> I've been thinking about this for a while. Is there any reason why
> jhalfs doesn't use the $package-url entity to find out the tarball
> instead of assuming that there is a 1:1 mapping between package and
> tarball?
> With a sma
M.Canales.es wrote:
In this case (headers installed from the kernel sources) the issue is about
html_page_name-->build_script_name-->package_name mapping, and that can't be
done until know how that new "Headers Installation" page will be called.
I was going to simply call it "Linux Headers" a
On Mon, 2006-09-25 at 21:35 +0100, Matthew Burgess wrote:
> Jim Gifford wrote:
>
> > the bottom line is that there will be some major breakages from the
> > headers_install, are you ready to tackle those?
>
> As Dan and I (at least) have previously stated, yes, we're prepared to
> tackle any BL
El Lunes, 25 de Septiembre de 2006 22:45, Matthew Burgess escribió:
> I was going to simply call it "Linux Headers" and have it being written
> out to "linux_headers.html". Does that help you at all?
Yes. With that we can know that the needed change is to replace in
get_package_tarball_name() f
On 9/25/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
El Lunes, 25 de Septiembre de 2006 22:45, Matthew Burgess escribió:
> I was going to simply call it "Linux Headers" and have it being written
> out to "linux_headers.html". Does that help you at all?
Yes. With that we can know that the needed
Dan Nicholson wrote:
On 9/25/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
El Lunes, 25 de Septiembre de 2006 22:45, Matthew Burgess escribió:
> I was going to simply call it "Linux Headers" and have it being written
> out to "linux_headers.html". Does that help you at all?
Yes. With that we ca
El Lunes, 25 de Septiembre de 2006 23:12, Dan Nicholson escribió:
> > linux-headers) echo $(grep "^linux-headers.*.bz2"
> > $JHALFSDIR/pkg_tarball_list | head -n1 ) ;;
>
> But the tarball name will probably not be linux-headers-*.bz2. It will
> probably be linux-2.6.18.x since you do the installat
On 9/25/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
What about something like:
tar -xf linux-2.6.18.x.tar.bz2
cd linux-2.6.18.x
mkdir /tools/tmp
make mrproper
make headers_check # For testing
make INSTALL_HDR_PATH=/tools/tmp headers_install
cp -R /tools/tmp/include/* /tools/include
rm -r /to
On 9/25/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
Personally, I think this should be tackled in a 2-step approach. 1)
Simple version bump to 2.6.18. 2) Drop linux-libc-headers installation,
replacing it with 'make headers_install' from the kernel tarball.
Oh, yeah. I got sidetracked read
Dan Nicholson wrote:
On 9/25/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
What about something like:
tar -xf linux-2.6.18.x.tar.bz2
cd linux-2.6.18.x
mkdir /tools/tmp
make mrproper
make headers_check # For testing
make INSTALL_HDR_PATH=/tools/tmp headers_install
cp -R /tools/tmp/include/* /t
Dan Nicholson wrote:
> Here are the relevant make bits:
>
> $(Q)unifdef -Ux /dev/null
Hmm; it looks like unifdef is not included in the kernel tree. We're
going to have to add this to chapter 5. (Actually we'll have to build
it just before the kernel headers install in chapter 5; then we
On 9/25/06, Bryan Kadzban <[EMAIL PROTECTED]> wrote:
Dan Nicholson wrote:
> Here are the relevant make bits:
>
> $(Q)unifdef -Ux /dev/null
Hmm; it looks like unifdef is not included in the kernel tree. We're
going to have to add this to chapter 5. (Actually we'll have to build
it just be
The CLFS Development team is pleased to announce the final release of
CLFS-1.0.0, code-name "Bender". This release features Glibc 2.4, GCC
4.1.1, Binutils 2.17, and supports the x86, x86-64, sparc, powerpc,
ppc64, mips, mips64, and alpha, including multilib on those arch's
that support it. Cross
On Monday 25 September 2006 23:20, M.Canales.es wrote:
> ...
> > The only gotcha is in the last step because headers_install does `rm
> > -rf $INSTALL_HDR_PATH/include'. So, maybe we'd want to let it install
> > in the kernel tree and copy it ourselves. But, that's basically what
> > you'll be up a
On Monday 25 September 2006 19:24, Matthew Burgess wrote:
> Just wondering what the preferred approach would be for upgrading Linux
> to the latest version (2.6.18 at the time of writing)? Previously,
> we've just upgraded the kernel regardless of the headers it wants
> installed because of having
Bryan Kadzban wrote:
> Hmm; it looks like unifdef is not included in the kernel tree. We're
> going to have to add this to chapter 5. (Actually we'll have to build
> it just before the kernel headers install in chapter 5; then we might as
> well just use the version from /tools in chapter 6 also
25 matches
Mail list logo
