Solved Debian update - keyboard responsive, Lennart Sorrenson not so much

Mon Oct 31 20:18:56 UTC 2011

Ok Lennart even though I've been told you can't pour more water into a
full glass, still I'm going to try.

On Mon, Oct 31, 2011 at 1:36 PM, Lennart Sorensen
<lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org> wrote:
> On Mon, Oct 31, 2011 at 12:57:30PM -0400, Russell Reiter wrote:
>> It's what you take out of my message which changes the meaning and
>> intent. I just don't like people snipping out their words and leaving
>> mine in, like you did in this snippet:
>
> Are you complaining about following proper qouting style on a mailing
> list?  That's the only thing I can think you mean.
>
>> <snip message>
>> > Simply rename the incorrect script to anything you want as long as it
>> > doesn't start with K.  Then you will have solved the original problem
>> > and NOT created a new one.
>> >
>> > But hey if you think you are smarter than the udev package maintainer,
>> > go ahead.  Break your system.  Who cares.
>>
>> Nope I'm not smarter than him.
>>
>> Debian just uses LSB headers to deal with package maintainers.
>
> I remember that line.  I still doesn't make sense this time.
>
> "package maintainers" are human beings that maintain packages.
> "Debian" is the organization that makes Debian releases
> "LSB headers" are a chunk of text put into the init scripts to tell
> insserv and similar what dependancies and defaults an init script has.
>
> How exactly does Debian use LSB headers to do anything with the humans
> that maintain packages?  I just can't figure that one out.

Debian is an organization made up of humans. Package maintainers are
humans, although some might argue differently. The organization Debian
realized that there are problems developing and maintaining packages
in the current manner.

Dealing with an event driven kernel requires some elegance in a
solution, elegance and and a modicum of recycling of code, at least in
transition.

This is part of that decision process in terms of when and how to
inject and monitor commands in the  initialization of the OS.

On Sat, Mar 26, 2005 at 10:02:51AM +0100, Thomas Hood wrote:
> > Changes:
> >  lsb (2.0-6) unstable; urgency=low
> >  .
> >    * Create lsb package in binary-indep step.  (Closes: #297788)
> >    * Merge /lib/lsb/init-functions from Ubuntu.
> >    * Split /lib/lsb/init-functions into arch-all lsb-base package; this
> >      functionality is thus available for use by other, non-LSB packages.
> >    * Update README.Debian.
>
>
> Should Debian initscripts use lsb init-functions?

Yes, IMHO it should, and it has been requested before (#208010). There are
several issues with the way init scripts are written by developers
currently:

- no uniformity, messages are show in a "messy" way and it's not easy to
tell when the system has started up correctly and when it has failed

- not all init scripts share the same arguments, some useful arguments are
not common (like 'status', #291148)

- there is no logging of init scripts (#169600) startup, so it's difficult
to determine (post-boot) if all the system's elements started up correctly.

- adding common library functions for LSB scripts could allow us to
provide an 'interactive login' such as the used by other distributions
and which is, actually, quite useful for new installations (to
determine which init.d script is freezing the system due to hardware
trouble).

There are more advantages than those above, but those above are the ones
that I would like to see fixed first :-)

Regards

Javier

>
>> <end of message>
>>
>> But hey, thanks for the input.
>
> Apparently not.
>
> I guess I should learn to stop bothering a lot sooner.
>
> I often forget some people just want answers or solutions without caring
> t<>> > But hey if you think you are smarter than the udev package maintainer,
>> > go ahead.  Break your system.  Who cares.
>>o learn and gain knowledge.

You were the one that warned about not taking the advice of people who
don't know what they are doing.

>
> As for not helping originally, well I really had no idea why your keyboard

Is this you admitting you didn't really have an idea, oh my god
Lennart, get a grip on things.

> stopped responding.  I had never encountered anything like it.  Of course
> I had never encountered a system where udev was being started twice.
> It's not supposed to happen.  It does seem like a bad udev design that
> attempting to start it twice can break things.  Rather unfortunate.
> The Bug you found had the right problem and the cause, just the wrong
> solution.  The right solution was discussed later in the comments on
> the bug.

What was the right solution you speak of? This is what I got from that thread.

"It seems that this bug is still not understood, and not readily
reproducible, so I don't think we should delay squeeze for it.  If/when
a fix becomes available it can still be considered, either before the
release or for a point update."

You see from my point of view, in all this there is no right or wrong,
only functional and non-functional.

Since both keyboards and mice work when they are plugged in, hot or on
boot, as well as the other usb device's I had to fool with at the
time, the usb Multi Function Unit and various usb dongles, what's
broken here?

I can't tell from the hardware and neither can you from your theories.
Yet you pontificate on the right solution, when you still don't
understand the problem.

That's what's broken here Lennart, you don't understand the problem.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208010

>
> --
> Len Sorensen
> --
> The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
>
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists