Chris Staub wrote these words on 01/05/06 01:39 CST:
> Because, as I understand it (which I don't very well myself) 2.6.15 is
> the first kernel that can actually handle hardware hotplugging with udev
> (and without hotplug) and you can't necessarily expect anyone to get
> something perfectly
Chris Staub wrote:
And a bug that comes up when you try to use a non-modular kernel. Or is
this what you were talking about? :)
That's different. What you are talking about is a bug in the script
contributed by myself. Counts better as my bug, not upstream bug.
--
Alexander E. Patrakov
Don'
Jim Gifford wrote:
I know this is a topic a lot of people are interested in. How to get
udev hotplugging working.
And I already provided a way of getting this working without a need for
the package that the cross-lfs team has provided. This is in the
archives for last month, so I'm not going
Alexander E. Patrakov wrote:
Randy McMurchy wrote:
Jim Gifford wrote these words on 01/04/06 23:53 CST:
I know this is a topic a lot of people are interested in. How to get
udev hotplugging working.
As I am obviously naive to what you are talking about, what exactly
doesn't work with the LF
Randy McMurchy wrote:
Chris Staub wrote these words on 01/05/06 01:21 CST:
Um, no, it's the hotplug folks that aren't updating (or, more
accurately, hotplug devs no longer seem to exist). The udev devs are
still actively maintaining and updating udev.
Perhaps, my ignorance is really shining
Randy McMurchy wrote:
Aren't Udev rules just a couple of files?
they also call custom scripts via their "RUN+=..." portions. And new
rules have been split into many files, according to their purpose
(old-school device naming, persistent Solaris-like device naming that
solves non-Ethernet eq
Randy McMurchy wrote:
Jim Gifford wrote these words on 01/04/06 23:53 CST:
I know this is a topic a lot of people are interested in. How to get
udev hotplugging working.
As I am obviously naive to what you are talking about, what exactly
doesn't work with the LFS implementation of udev hotpl
Chris Staub wrote these words on 01/05/06 01:21 CST:
> Um, no, it's the hotplug folks that aren't updating (or, more
> accurately, hotplug devs no longer seem to exist). The udev devs are
> still actively maintaining and updating udev.
Perhaps, my ignorance is really shining through, but your e
Randy McMurchy wrote:
Chris Staub wrote these words on 01/05/06 00:57 CST:
It's the process of dropping hotplug and replacing it entirely with
udev, since hotplug is old and unmaintained - the idea is it provides
essentially the same functionality, but 1 fewer package to worry about.
What ex
Bruce Dubbs wrote:
Recently there has been a lot of activity in the LFS community. There
has been especially important activity in internationalization (i18n)
and cross-LFS (CLFS) that has the potential to to expand the horizon of
BLFS significantly.
We have already started putting some i18n in
Chris Staub wrote these words on 01/05/06 00:57 CST:
> It's the process of dropping hotplug and replacing it entirely with
> udev, since hotplug is old and unmaintained - the idea is it provides
> essentially the same functionality, but 1 fewer package to worry about.
What exactly is upstream's
Chris Staub wrote these words on 01/05/06 00:53 CST:
> Randy McMurchy wrote:
>>Again, what is wrong the the released tarballs? Why do we need to
>>use custom ones?
>
> Jim's message was a little confusing here. The tarball consists of new
> udev *rules*, not a new udev package.
Well, now I confu
Randy McMurchy wrote:
Jim Gifford wrote these words on 01/04/06 23:53 CST:
I know this is a topic a lot of people are interested in. How to get
udev hotplugging working.
As I am obviously naive to what you are talking about, what exactly
doesn't work with the LFS implementation of udev hotplug
Randy McMurchy wrote:
Jim Gifford wrote these words on 01/04/06 23:53 CST:
Third you will need the udev package that the Cross-LFS team developed.
Again, what is wrong the the released tarballs? Why do we need to
use custom ones?
Jim's message was a little confusing here. The tarball consist
Jim Gifford wrote these words on 01/04/06 23:53 CST:
> I know this is a topic a lot of people are interested in. How to get
> udev hotplugging working.
As I am obviously naive to what you are talking about, what exactly
doesn't work with the LFS implementation of udev hotplugging? I'm
not trying
Jim Gifford wrote:
I know this is a topic a lot of people are interested in.
Sure. I also have some ideas (mainly about adding some rules for
debugging and some text about LibUSB, SANE and GPhoto2). I will express
them after dealing with Randy's wish for the UTF-8 LFS book to come with
BDB i
I know this is a topic a lot of people are interested in. How to get
udev hotplugging working. It's not a simple procedure, but I got it to
work on a Sparc so it should work for everyone. Any changes or comments
are welcomed, but I figured I would share the news.
First off, you will need to pa
On 1/4/06, Greg Schafer <[EMAIL PROTECTED]> wrote:
>
> No. It's more complicated than that :-/ GCC also has a say in the library
> search path too. This is why the startfile_prefix_spec hack to GCC makes
> it (mostly) do the right thing.
The directory is passed as a -L flag to the linker by gcc.
Alexander E. Patrakov wrote:
> Tushar Teredesai wrote:
>> In the ncurses instructions, you use the INPUT method to force linking
>> against the widec versions. Wouldn't it be easier to just use symlinks
>> like we do for ncurses? Or is there a particular reason for choosing
>> the INPUT method?
>
Tushar Teredesai wrote:
> It found the libgcc_s in
> /tools/lib/gcc/i686-pc-linux-gnu/4.0.2/../../../libgcc_s.so.
> Confirmed. Though it did come as a surprise. When I tried the test
> that you mentioned, it found the glibc libraries in /tools/lib, not in
> /usr/lib. I checked the command that
Tushar Teredesai wrote:
In the ncurses instructions, you use the INPUT method to force linking
against the widec versions. Wouldn't it be easier to just use symlinks
like we do for ncurses? Or is there a particular reason for choosing
the INPUT method?
If symlinks are used, the "ldconfig" progr
Jeremy Huntwork wrote:
Dan, Chris:
I see you guys have done a lot of work over the past week. Thank you
very much for that. I'm having a little trouble sorting through the
hundreds of emails in my Inbox today and pinpointing exactly what
changes are ready to go into the alpha branch.
Would
Alan Lord wrote:
Anyway, a little while ago (November?) I reported a problem with the
liveCD (I think it was a 6.1-preSomething version) which was that it
failed to boot correctly if the CD was in /dev/hdb rather than
/dev/hda. Basically when the booting script checks for the CD's
existence
On Wed, Jan 04, 2006 at 12:03:53AM -0500, Jeremy Huntwork wrote:
>
> "Package managers are for wimps! -Archaic"
:D
--
Archaic
Want control, education, and security from your operating system?
Hardened Linux From Scratch
http://www.linuxfromscratch.org/hlfs
--
http://linuxfromscratch.org/mail
On 1/4/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
Sorry for the cross posting nonsense. We got off list and I put the
wrong address back in.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
#cc -v hello.c
Reading specs from /tools/lib/gcc/i586-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/tools --libexecdir=/tools/lib
--with-local-prefix=/tools --enable-clocale=gnu --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++
--d
On 1/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Sorry, forgot to CC you...
You can just send everything to the list unless you'd rather ask a
question off of it. I'm adding lfs-dev back in.
> #cc hello.c
> /tools/lib/gcc/i586-pc-linux-gnu/3.4.3/../../../../i586-pc-linux-gnu/bin/ld:
> c
Hi,
forgive me posting to this list but I use gmane and there isn't a group
for the LiveCD.
Anyway, a little while ago (November?) I reported a problem with the
liveCD (I think it was a 6.1-preSomething version) which was that it
failed to boot correctly if the CD was in /dev/hdb rather tha
Just in case anyone was interested, it looks like we're getting close
to glibc-2.4.
http://sources.redhat.com/ml/libc-alpha/2006-01/msg00016.html
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Dan Nicholson wrote:
Until they finally kick me off their server, I've got a little repo of
stuff trying to track my work on this:
http://students.washington.edu/dbnichol/lfs/
[snip]
For sure take a look at the ChangeLog to see a quick summary.
OK, thanks, Dan. This helps a lot. I'll try t
On 1/4/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Would you guys mind giving me a little summary of the progress of the
> last week? Also, Chris, I believe you have a patch for the book, right?
> Which is the current one?
Until they finally kick me off their server, I've got a little repo of
Dan Nicholson wrote:
OK, but in this case it was useful. Putting bison in Ch.5, and moving
flex before bison in Ch. 6 has cleared up the ICA differences. Later
I'll actually look at the bison source a bit to confirm this, but I'm
pretty sure there's a circular dependency here. flex uses bison,
Alexander E. Patrakov wrote:
> The question is how the book should handle this. Valid options:
>
> 1) Upgrade nano to 1.3.9 and briefly explain the reason on its page.
> Don't add anything to the "locale related issues" page because the issue
> is completely resolved.
>
> 2) Keep both nano-1.2.5
On 1/4/06, Tushar Teredesai <[EMAIL PROTECTED]> wrote:
> On 1/3/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> > For evidence, here's a diff of the build logs between iter1 and iter2 for
> > bison:
> >
> > --- iter1/bison-2.1.log 2005-12-29 11:50:40.0 -0800
> > +++ iter2/bison-2.1.log 2005
Jeremy Huntwork wrote:
I went to our bugzilla to add this if no one else had already. Guess
what quips.cgi decided to pull up for the quote?
"Package managers are for wimps! -Archaic"
Amen.
Andy
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
On 1/3/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
> For evidence, here's a diff of the build logs between iter1 and iter2 for
> bison:
>
> --- iter1/bison-2.1.log 2005-12-29 11:50:40.0 -0800
> +++ iter2/bison-2.1.log 2005-12-29 13:28:54.0 -0800
> @@ -79,8 +79,7 @@
> checking for
On 1/4/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
>
> I have updated the UTF-8 patch. The new version is available at:
>
> http://www.linuxfromscratch.org/~alexander/patches2/lfs_book-r7243-utf8-1.patch
>
> The rendered version is at:
>
> http://www.linuxfromscratch.org/~alexander/lfs-boo
Alexander E. Patrakov wrote these words on 01/04/06 10:16 CST:
> OK, I will build LFS and update the patch tomorrow. Comments on other
> parts of the patch are still welcome.
>
> Should I use DB-4.3.29 or 4.4.16?
I used 4.4.16 in my most recent build. I did not update BLFS to this
version. Ther
Randy McMurchy wrote:
Can't the patch be delayed until DB is put in?
OK, I will build LFS and update the patch tomorrow. Comments on other
parts of the patch are still welcome.
Should I use DB-4.3.29 or 4.4.16?
--
Alexander E. Patrakov
Don't mail to [EMAIL PROTECTED]: the server is off unt
Alexander E. Patrakov wrote these words on 01/04/06 08:20 CST:
> Please apply the patch, and, in the case if it is unsuitable as a whole,
> please don't revert parts that are actually OK.
I thought it was almost 100% choice of folks that responded to use
DB instead of the GDBM database. I realiz
Hello,
I have updated the UTF-8 patch. The new version is available at:
http://www.linuxfromscratch.org/~alexander/patches2/lfs_book-r7243-utf8-1.patch
The rendered version is at:
http://www.linuxfromscratch.org/~alexander/lfs-book/
Changes:
* Implemented the install_root=/ method for suppre
41 matches
Mail list logo
