On 1/13/2006 00:27, Lennon Cook wrote:
> Jim Gifford wrote:
>> If you follow LKML and Greg KH's comments you will understand all the
>> current issues with uevent and sysfs.
>
> Can you please provide links for those of us who don't follow these lists?
In the meantime it might be worth a quick lo
Jim Gifford wrote:
> If you follow
> LKML and Greg KH's comments you will understand all the current issues
> with uevent and sysfs.
Can you please provide links for those of us who don't follow these lists?
--
Lennon Victor Cook
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http:/
Matthew Burgess wrote:
Dan Nicholson wrote:
He sent this email [2] to the llh-announce list in November about being
swamped with work, but nothing's happened since then. Any more
information about this?
Nope, that's the last email I've received on the subject. I didn't spot
the fact that
Dan Nicholson wrote:
He sent this email [2] to the llh-announce list in November about being
swamped with work, but nothing's happened since then. Any more
information about this?
Nope, that's the last email I've received on the subject. I didn't spot
the fact that he sent it to the llh-anno
On 1/6/06, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Yes, that's right, sorry. I was confusing his message with a reply to
> it which suggested it may be more sensible for the maintainers to
> concentrate on getting the 2.6.15 headers ready, rather than worry about
> the already (relatively) ou
Tim van der Molen wrote:
The llh maintainer only said he would try to release 2.6.14 in December
2005. He did not say anything about 2.6.15. Right?
Yes, that's right, sorry. I was confusing his message with a reply to
it which suggested it may be more sensible for the maintainers to
concent
Matthew Burgess wrote:
Andrew Benton wrote:
This sounds good, but I don't like the idea of waiting for a new
release of linux-libc-headers. I'm not sure we'll see a new release
before the end of the year.
As in end of 2006? That's rather pessimistic! Especially considering I
let folks kn
Jim Gifford wrote:
First off, you will need to patch the kernel. 2.6.15 is not all the way
there, but GregKH has the necessary patches available to make it work. I
used
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.15.patch
404 Not Found
Actually, moved to
Jim Gifford wrote:
> Maybe I should not post these types of advances anymore, it just seems
> to get everyone in an uproar over nothing.
Plese *do* continue to post. Like others, I have been following the
discussion. As others have mentioned, your posts have been a little
sparse on technical/im
On Thu, Jan 05, 2006 at 06:54:53PM -0800, Jim Gifford wrote:
>
> Anyone who has been following the kernel and hotplug development lists
> know that hotplug is depreciated.
I don't and can't follow either of them. No editor can be expected to be
an expert on every topic or to follow every technol
On 1/5/06, Ryan Oliver <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-01-05 at 18:20 -0700, Archaic wrote:
> > People reading this list are expected to be
> > interested in development otherwise there is no reason to read it.
>
> For base development of the book I agree.
>
> For banging on bleeding edge
On Jan 5, 2006, at 8:54 PM, Jim Gifford wrote:
Anyone who has been following the kernel and hotplug development
lists know that hotplug is depreciated. Even on the lfs-dev,
numerous times it has been mentioned about removing hotplug. So
it's nothing new, I just have a working solution for
Archaic wrote:
Jim, please, chill. What is being asked for is some rationalization.
Some filtering of weeks/months/whatever worth of who knows how many
lists into a nice concise "why". Saying that is fixes things isn't
much of an explanation. Randy didn't question that it worked. In fact he
was
Archaic wrote:
When did I refuse to debug? Being unable to debug is quite likely, but
refusing? I'm moving as fast as I can with a 50 hour a week work
schedule and full time graduate work. Geez.
Sorry for bad wording then. But I asked you to send the output of "find
/sys/bus/usb" and "DEBUG=ye
On Thu, 2006-01-05 at 18:20 -0700, Archaic wrote:
> On Fri, Jan 06, 2006 at 12:11:06PM +1100, Ryan Oliver wrote:
> >
> > +1, it should never have been removed.
>
> I just don't understand why development shouldn't happen on a
> development list? Why shouldn't technical threads be here? This is wh
On Fri, Jan 06, 2006 at 12:11:06PM +1100, Ryan Oliver wrote:
>
> +1, it should never have been removed.
I just don't understand why development shouldn't happen on a
development list? Why shouldn't technical threads be here? This is what
lfs-dev has always been about. lfs-hackers, IMO, was ill-co
On Thu, 2006-01-05 at 19:43 -0500, Joel Miller (RIT Student) wrote:
> Having read this list for a long time, I too would like to see lfs-hackers
> reinstated where stuff can be thrown about and tested so that it can be
> refined before it is brought to this list where the tough questions of
> ge
Jim Gifford wrote:
> I get tired of people saying I'm keeping everything secret of what I'm
> doing. I brought what I found to the masses now that it works properly,
> and now I'm getting harassed for it. Do I really deserve this treatment,
> I don't think so. I'm tired of this crap, especially
Jim Gifford wrote:
> Tushar Teredesai wrote:
>
>> On 1/5/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>>
>>
>>> why would LFS consider doing a bunch of patching and such when it is
>>> just a guess if this is what is going to be coming down the pipe in
>>> just a couple of weeks with these new
On Thu, Jan 05, 2006 at 11:55:52AM -0800, Jim Gifford wrote:
>
> I get tired of people saying I'm keeping everything secret of what I'm
> doing. I brought what I found to the masses now that it works properly,
> and now I'm getting harassed for it.
Jim, please, chill. What is being asked for is
On Thu, Jan 05, 2006 at 12:38:18PM +0500, Alexander E. Patrakov wrote:
>
> Really, nothing (save for one report by Archaic where he refused to help
> debugging). It's just deprecated upstream.
When did I refuse to debug? Being unable to debug is quite likely, but
refusing? I'm moving as fast as
Andrew Benton wrote:
This sounds good, but I don't like the idea of waiting for a new release
of linux-libc-headers. I'm not sure we'll see a new release before the
end of the year.
As in end of 2006? That's rather pessimistic! Especially considering I
let folks know back in November
(htt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chaps,
can we put a little prespective on this.
Its a dev-list, a development process has been put forward to the list
for fun/evaluation/testing/feedback, this is not in lfs or
cross-lfsyet, Matts done work on this also which I tested in the
ea
Jim Gifford wrote:
Tushar Teredesai wrote:
On 1/5/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
why would LFS consider doing a bunch of patching and such when it is
just a guess if this is what is going to be coming down the pipe in
just a couple of weeks with these new versions you mentio
Jeremy Huntwork wrote:
Andrew Benton wrote:
This sounds good, but I don't like the idea of waiting for a new
release of linux-libc-headers. I'm not sure we'll see a new release
before the end of the year. Is there a plan B?
Plan B -> Proceed with everything else and either skip upgrading l
Andrew Benton wrote:
This sounds good, but I don't like the idea of waiting for a new release
of linux-libc-headers. I'm not sure we'll see a new release before the
end of the year. Is there a plan B?
Plan B -> Proceed with everything else and either skip upgrading llh, or
pull from llh's re
Matthew Burgess wrote:
the only reason my work has not hit the book is
we're still waiting on linux-libc-headers. Once that's in, the plan of
attack will be:
1) Upgrade kernel+llh
2) Upgrade udev, remove hotplug and patch the bootscripts to not install
the hotplug script and fix the udev scr
Tushar Teredesai wrote:
On 1/5/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
why would LFS consider doing a bunch of patching and such when it is
just a guess if this is what is going to be coming down the pipe in
just a couple of weeks with these new versions you mention?
I don't thi
Randy McMurchy wrote:
As far as you saying that I've commented on these issues, it is
funny you say that. Of all the links you provided to threads, the
only comments I've made is that you are too secretive and won't
share knowledge with the community.
Everything has been laid out on the hotplug
On 1/5/06, Randy McMurchy <[EMAIL PROTECTED]> wrote:
>
> why would LFS consider doing a bunch of patching and such when it is
> just a guess if this is what is going to be coming down the pipe in
> just a couple of weeks with these new versions you mention?
I don't think Jim is proposing adding th
Jim Gifford wrote these words on 01/05/06 11:09 CST:
> I talked about this packages so many times on the lists, why don't you
> just pay attention,
Thanks for your condescending attitude, Jim. But it doesn't bother
me, perhaps I deserve it. Who knows?
What I do know, however, is that I have a f
Tushar Teredesai wrote:
(Based on previous posts to lfs-dev) I was under the impression that
the udev and hotplug is maintained by the same team and that the
hotplug package is being depracated and udev will be the new hotplug
handler.
That is correct. Basically hotplug is now one line in t
On 1/5/06, Chris Staub <[EMAIL PROTECTED]> wrote:
>
> 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.
(Based on previous posts to lfs-dev) I was under the impression
Randy McMurchy wrote:
Thanks to you and Alex for your continued patience with me on this,
and for your answers so far. Now, with all due respect to Jim's work,
why would LFS consider doing a bunch of patching and such when it is
just a guess if this is what is going to be coming down the pipe in
Matthew Burgess wrote:
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 to repeat it here. What I
will say though is that the only reason my work has not hit the
Alexander E. Patrakov wrote:
Randy McMurchy wrote:
First off, you will need to patch the kernel. 2.6.15 is not all the
way there, but GregKH has the necessary patches available to make it
work. I used
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.15.patch
Matthew Burgess wrote:
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.
s/working/working in LFS/. New
Matthew Burgess wrote:
> [...] things like edd_id and dasd_id aren't
> necessary on an x86 as far as I can tell).
Actually, I am not aware of any platform *except* x86 that does have
EDD or anything remotely like it. No platform except x86 uses this 25
year old abonimation called BIOS, so no plat
Randy McMurchy wrote:
Thanks to you and Alex for your continued patience with me on this,
and for your answers so far. Now, with all due respect to Jim's work,
why would LFS consider doing a bunch of patching and such when it is
just a guess if this is what is going to be coming down the pipe in
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
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
55 matches
Mail list logo
