Dan Nicholson wrote:
One reason is that the headers in the kernel source include all the
internal kernel definitions. As I understand it, it's bad form for
userland apps to be using internal kernel interfaces (with the
exception of glibc).
That doesn't sound too dangerous to me. Surely the hea
Hi all,
I believe this has been discussed before, but after reading a post on
lfs-chat recently and some pretty frustring issues within the support
IRC channels, I thought I'd post this open question.
Should there be an "unsupported distro" page in the book.
eg: the slamd64 distro is totally
i would suggest to open up a db like it was done with the SBUs.
then users can repport if their host is capable of building lfs and others
can look into it.
then a statistical view of the entries could be given like:
suse x.y
10 users without problems
2 users with minor issues
1 user with really
Matt Darcy wrote:
Hi all,
I believe this has been discussed before, but after reading a post on
lfs-chat recently and some pretty frustring issues within the support
IRC channels, I thought I'd post this open question.
Should there be an "unsupported distro" page in the book.
Yes, althoug
Andrew Benton wrote:
> That doesn't sound too dangerous to me.
Except that the kernel headers use different names (and possibly
different types, although the types have to be the same size) from what
userspace needs to use.
For instance, see:
http://groups.google.com/group/linux.kernel/browse_fr
Matthew Burgess wrote:
If folks are happy enough having a mismatched version of kernel vs.
userspace headers I'm more than willing to upgrade the kernel just so
we can get all this udev mess behind us.
Note that after the first time the user upgrades his kernel (e.g. for
security reasons), h
Bryan Kadzban wrote:
Andrew Benton wrote:
If it is wrong to use the kernel headers why don't the kernel
developers include fixed headers in with the kernel source?
Because the linux-libc-headers project already exists. (Now, this
wasn't a valid answer until recently, but until 2.5.something,
while [ $(cat /proc/*/status 2> /dev/null | grep -c -E
'^Name:.udevd?$')
-gt 1 ]; do
sleep 1
done
thanks, added this to my script!
Your configuration doesn't autoload modules when one plugs a USB
device (e.g. a flash drive) in. You need to add "modalias" rules for
this.
I don't really unde
[EMAIL PROTECTED] wrote:
Your configuration doesn't autoload modules when one plugs a USB
device (e.g. a flash drive) in. You need to add "modalias" rules for
this.
I don't really understand.. the official way to do things now is
loading modules manually via modprobe at startup, right? with
Hi all,
Though there is a sed that is supposed to suppress the installation
of the 'groups' man pages, it apparently only suppresses the English
version. Note:
[EMAIL PROTECTED]: ~/build > grep groups
/mnt/rmlnew1/build/shadow-4.0.13/install.log
/usr/bin/install -c -m 644 './groups.1' '/usr/man
Randy McMurchy wrote:
Though there is a sed that is supposed to suppress the installation
of the 'groups' man pages, it apparently only suppresses the English
version.
Thanks, could you try the following instead please:
find man -name Makefile -exec sed -i '/groups/d' {} \;
Regards,
Matt.
-
Matthew Burgess wrote:
> Randy McMurchy wrote:
>
>> Though there is a sed that is supposed to suppress the installation
>> of the 'groups' man pages, it apparently only suppresses the English
>> version.
>
>
> Thanks, could you try the following instead please:
>
> find man -name Makefile -exec
Bruce Dubbs wrote:
Wouldn't just removing man (and possibly po) and regenerating
Makefile.in the simplest way to go?
Surely then we'd lose all of shadow's man pages? Or am I missing
something? (quite likely - I'm wearing my release manager's hat tonight,
not my LFS builders helmet!)
Matt.
Matthew Burgess wrote:
> Bruce Dubbs wrote:
>
>> Wouldn't just removing man (and possibly po) and regenerating
>> Makefile.in the simplest way to go?
>
>
> Surely then we'd lose all of shadow's man pages? Or am I missing
> something? (quite likely - I'm wearing my release manager's hat tonight,
The Linux From Scratch community is pleased to announce the second
pre-release of LFS 6.1.1. In addition to the fixes already made in
LFS-6.1.1-pre1, this release addresses a bug in Glibc that prevents some
programs (including OpenOffice.org) from running.
You can read the book online at
http
Good job and a big thanks to everybody involved in getting this version
released.
--
Gerard Beekmans
/* If Linux doesn't have the solution, you have the wrong problem */
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the abo
Hi folks,
LFS-6.1.1 is nearly upon us. With that in mind, I'd like to outline
what I'd like to see happen on trunk before we branch for our first
gcc-4.x based release.
1) Merge the alphabetical build order branch. If nothing else, this
helps us explain why we build things in the order we
Matthew Burgess wrote:
1) Merge the alphabetical build order branch. If nothing else, this
helps us explain why we build things in the order we do (i.e. fix bug
684). Thanks to Chris Staub's analyses, the dependencies listed against
each package will be more accurate too.
At this point a su
Gerard Beekmans wrote:
Matthew Burgess wrote:
1) Merge the alphabetical build order branch. If nothing else, this
helps us explain why we build things in the order we do (i.e. fix bug
684). Thanks to Chris Staub's analyses, the dependencies listed
against each package will be more accurate
Matthew Burgess wrote:
Agreed, I've actually lost track of its status too, so I'll have to let
Jeremy get us all up to speed I think :-)
Chris is working on the list of dependencies for the textual part of the
book, and I think he's already got a fair amount done. As of now, the
build orde
On 11/24/05, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> However, Dan Nicholson pointed out some gcc test failures on that branch
> which I'd like to see investigated. Dan can you verify that and/or does
> anyone know if these are a cause for concern?
My status with the alphabetical build:
Built
On Wed, 23 Nov 2005 12:13:25 -0800, Dan Nicholson wrote:
> === libmudflap Summary ===
>
> # of expected passes1282
> # of unexpected failures6
> FAIL: libmudflap.cth/pass40-frag.c execution test
> FAIL: libmudflap.cth/pass40-frag.c output pattern test
> FAIL: libmudflap.cth/pa
Matthew Burgess wrote:
> though I think proper handling of the input subsystem is still
> dependent on linux-2.6.15.
I've booted 2.6.14 without hotplug set up while I was doing my initramfs
testing (the kernel hotplug handler got set to "" by the initramfs). I
got a warning from the input subsyst
Greg Schafer wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003
Despite the title of that PR, the problem is not related to timeouts AFACT.
Thanks for this. Also, I've just noticed that Randy has the same FAILs
in his build as well, so it's not isolated to the lfs-alphabetical
branch
Jeremy Huntwork wrote these words on 11/24/05 20:30 CST:
> Greg Schafer wrote:
>>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003
>>
>>Despite the title of that PR, the problem is not related to timeouts AFACT.
>
> Thanks for this. Also, I've just noticed that Randy has the same FAILs
> in his b
Randy McMurchy wrote:
Anyway, best I can remember, I thought I read where you guys weren't
changing the order of the toolchain packages. If so, what does gcc
errors (libmudflap problems) have to do with anything?
Yep, you're right, it wouldn't, (unless of course the gcc build in
chapter 6 got
Matthew Burgess wrote:
If anyone wants any other features included now's the time to get those
requests in. At the moment, I'm considering branching off for
stabilisation in around 4 weeks time (though with that being very close
to Christmas, it may slip a little). Only time will tell if that
Jeremy Huntwork wrote these words on 11/24/05 20:58 CST:
> I've been reading and attempting to apply in my spare time Matthias
> Benkmann's hint, 'More Control and Package Management using Package
> Users'.
>
> So. I had been thinking it would be nice if LFS and BLFS adopted (some
> of) this a
Randy McMurchy wrote:
Jeremy Huntwork wrote these words on 11/24/05 20:58 CST:
So. I had been thinking it would be nice if LFS and BLFS adopted (some
of) this approach.
-1
Vociferously. :-)
Not surprised. :) Although, giving some reasons for that stance would be
appreciated.
--
JH
--
h
Jeremy Huntwork wrote these words on 11/24/05 21:05 CST:
> Not surprised. :) Although, giving some reasons for that stance would be
> appreciated.
Because LFS is all about "Your Distro, Your Rules".
There are many package management systems. To employ one as the
standard for LFS purposes defeat
Randy McMurchy wrote:
Because LFS is all about "Your Distro, Your Rules".
There are many package management systems. To employ one as the
standard for LFS purposes defeats the whole purpose of "choice".
I had said "(some of)" but I should have explained it a bit further.
Matthias' hint is on
Randy McMurchy wrote:
Then Matt earlier mentioned, "at
least we'll have a good answer for folks that ask why we have the
build order as we do".
However, the build order is good now. It is known to work. If folks
ask, "How did you come up with this build order", the answer is
simply, "This order
DJ Lucas wrote:
And even that may not be the case still, as something may actually be
required by the later packages that is satisfied in the alphabetical
listing.
That is the case.
In the old books, all buildtime program dependancies were
listed...actual programs, not packages or libs IIRC
Jeremy Huntwork wrote these words on 11/24/05 21:23 CST:
> One
> point that hint me really hard was this:
>
> "Let's say I have written a program that you would like to use. To make
> it easier for you I come over to install it for you. Would you give me
> the root account and then leave the ro
DJ Lucas wrote:
Well, I'd personally like to know how our current build order took
shape! Unfortunately, the answer to this question lies scattered deep
It's quite straight-forward and simple. This goes back to when I started
LFS in the pre-1.0 days.
I basically started with a package, I t
Randy McMurchy wrote:
Again, hogwash. No admin worth a shit would ever do this.
No need for foul language.
Hand-holding isn't teaching. Making them understand how and why things
can go wrong, and how to prevent it, is what needs to be taught. The
root user is powerful. Users need to be taugh
DJ Lucas wrote these words on 11/24/05 21:28 CST:
> Well, I'd personally like to know how our current build order took
> shape! Unfortunately, the answer to this question lies scattered deep
> within _years_ of LFS archives, and I'm not sure that there is any
> written rational behind it elsew
Gerard Beekmans wrote:
That's how the process went until years later we arrive at our current
build system. The packages out of alphabetical order are in that
position to satisfy dependencies of other packages.
Except that as packages have changed and LFS has progressed, this
build-order has
Randy McMurchy wrote:
Then start reading. The information is there if you *really* would
"like to know".
Try to be a little realistic. If you wanted to read every email to
former lfs-discuss and now lfs-dev, you have to have a lot of time.
There is nearly seven years worth of postings. Hundre
Jeremy Huntwork wrote these words on 11/24/05 21:41 CST:
> No need for foul language.
Grow up, Jeremy. I don't mean that bad. I just mean that it is everyday
talk to most people. It isn't foul, it is an expression.
> This isn't hand-holding. Again go read the hint before you proclaim what
> it
Jeremy Huntwork wrote:
Except that as packages have changed and LFS has progressed, this
build-order has degraded somewhat. All the alphabetical branch is, is a
re-introducing of Gerard's original method for producing a build order
into the current framework of LFS.
See a comment in my previo
Randy McMurchy wrote:
> Jeremy Huntwork wrote these words on 11/24/05 21:23 CST:
>>It is a mystery why Unix admins who wouldn't even trust their employer
>>with more than a normal user account carelessly execute complex and
>>incomprehensible installation scripts with full root rights."
>
>
>
Gerard Beekmans wrote:
Compared to current LFS Trunk, what would exactly change when the
alphabetical branch is merged?
LFS-DEVELOPMENT
==
CHAPTER 5
# Binutils-2.16.1 - Pass 1
# GCC-4.0.2 - Pass 1
# Linux-Libc-Headers-2.6.12.0
# Glibc-2.3.6
# Adjusting the Toolchai
Jeremy Huntwork wrote these words on 11/24/05 21:05 CST:
> Not surprised. :) Although, giving some reasons for that stance would be
> appreciated.
Well, I believe I've satisfied that request. I'll bow out of this
thread now, as my opinion has been heard. I'm not going to dwell on
the same old st
Gerard Beekmans wrote:
See a comment in my previous email elsewhere in this thread. Gotto make
sure our toolchain is not affected. A configure script may not "bork"
when a package is missing, but it may behave differently when installing.
You really need to go back and read the bug. :)
We d
Randy McMurchy wrote:
Jeremy Huntwork wrote these words on 11/24/05 21:41 CST:
No need for foul language.
Grow up, Jeremy. I don't mean that bad. I just mean that it is everyday
talk to most people. It isn't foul, it is an expression.
I see. So a mature person has to resort to being coars
Randy McMurchy wrote:
I just didn't want to be considered as passing judgment on your
idea without offering a (what I consider) sound reason for
disagreeing with your suggestion.
Thank you. I do appreciate that you expressed yourself.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs
Jeremy Huntwork wrote:
> Gerard Beekmans wrote:
>
>> Compared to current LFS Trunk, what would exactly change when the
>> alphabetical branch is merged?
I think you can compare better with this:
LFS-DEVELOPMENT LFS-ALPHABETICAL
==
Bruce Dubbs wrote:
I think you can compare better with this:
[snip]
Thanks. :)
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Chris Staub wrote:
Nevermind, it looks like Xine will use libdvdcss itself (doesn't use
libdvdread)...in which case libdvdcss needs to be added to Xine's list
of dependencies. However, I don't know if dvdnav needs to be removed
from the Optional list...Xine *can* use an external dvdnav libra
Jeremy Huntwork wrote:
You really need to go back and read the bug. :)
I will. I just got lost in all the comments. Too bad it doesn't thread,
that'd be a helpful feature.
--
Gerard Beekmans
/* If Linux doesn't have the solution, you have the wrong problem */
--
http://linuxfromscratch.or
Matthew Burgess wrote:
Hi folks,
LFS-6.1.1 is nearly upon us. With that in mind, I'd like to outline
what I'd like to see happen on trunk before we branch for our first
gcc-4.x based release.
1) Merge the alphabetical build order branch. If nothing else, this
helps us explain why we build
Bruce Dubbs wrote:
Randy McMurchy wrote:
Jeremy Huntwork wrote these words on 11/24/05 21:23 CST:
It is a mystery why Unix admins who wouldn't even trust their employer
with more than a normal user account carelessly execute complex and
incomprehensible installation scripts with full root
Matthew Burgess wrote:
=
> If anyone wants any other features included now's the time to get those
> requests in.
Do you want to consider gcc-4.1?
http://gcc.gnu.org/gcc-4.1/
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscrib
Bruce Dubbs wrote:
Matthew Burgess wrote:
=
If anyone wants any other features included now's the time to get those
requests in.
Do you want to consider gcc-4.1?
http://gcc.gnu.org/gcc-4.1/
May I beg and plea for a good, healthy HELL NO? :-) With previous
release history, regressions
DJ Lucas wrote:
> Bruce Dubbs wrote:
>> Do you want to consider gcc-4.1?
>>
>> http://gcc.gnu.org/gcc-4.1/
>
>
> May I beg and plea for a good, healthy HELL NO? :-) With previous
> release history, regressions have been a pain...wait until at least
> 4.1.1 or 4.1.2 even to let the dust settle
Bruce Dubbs wrote:
Do you realize that lfs-devel has 4.0.2 now?
Yes I do. A full system update is coming soon as I am still on
glibc-2.3.5 and gcc-4.0.1. I was talking about the regressions I had
noticed previously showing up in a 'minor' version update of 3.3.4 to
3.4.0. Now, in this
Bruce Dubbs wrote:
In any case, I couldn't find a 4.1 tarball and did a svn checkout of the
4.1 branch.
That's because 4.1 has only just branched for their stabilisation. I'd
imagine the official release is still a good couple of months away,
given GCC's previous release schedules.
Regar
On Thu, 24 Nov 2005 21:58:24 -0500
Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> This is kind of a brave request, and I'm fully prepared to be shot down.
> In fact, I think I'd be surprised if the group went for it. ;) However
> after thinking about this for some time, I'm going to venture a requ
59 matches
Mail list logo
