[linux-dvb] patch collection for Kernel 2.6.16-rc1
uwe.bugla at gmx.de
Fri Feb 3 17:39:36 CET 2006
it seems to me that a couple of wrong information / misunderstandings must
be cleared right here:
1. at Johannes Stezenbach:
"Actually I do the work that I get paid for. Unfortunately, linuxtv.org /
linux-dvb stuff is not part of it.
Very interesting, if not astonishing in deed!
The MAINTAINERS file of the latest kernel says under "DVB SUBSYSTEM AND
DRIVERS" that the status is: SUPPORTED.
And "SUPPORTED" means: Someone is actually paid to look after this.
Now who contains the right information I can rely on? You, Johannes, or the
maintainers file? Who is that someone? God in the sky, the unknown soldier,
the omniscient author, Lucifer in hell, now who is responsible and being
paid for that service? Or have I just found another dead body of wrong
information in the kernel tree?
2. at Oliver Endriss:
"Nothing is perfect. We don't want a 'patch collection' but simple patches
which fix specific problems. The changes in dvb_frontend.c have nothing to
do with the rest. I cannot comment on the rest of the patch."
First of all: If you continue at least talking to me, stop using that "we"
to make yourself bigger than you are! Just use "I" and nothing else, OK? Its
in my experience german nationalists and american soldiers of the utmost
primitive kind who prefer to take "we" instead of "I" as soon as they start
to talk to sophisticated people like me. And I do not like nationalists of
any kind, OK?? Nor do I like american soldiers.
That does not mean that you are a german nationalist, nor does it mean that
you are a part of a consortium of legalized murderers. Its nothing more than
a connotation of my personal experience.
Second: I know that nothing is perfect. Quite clear! In consequent
opposition to your following sentence I want to make clear that I don't want
a discussion club whose output or price is that the group of cards I own
suffers a breakdown lasting for 3 months. I prefer groups of people taking
work into their hands, at least parts of this work to be done, not only
bla-bla-blaers (sorry, impolite statement, but radical and clear!). The
fault about bla-bla-bla is that it only produces more bla-bla-bla: Out of
nothing results nothing, that is very simple!
In other words: The transition from Kernel 184.108.40.206 to Kernel 2.6.15-rc1 has
been a far too radical cut in my personal opinion.
And that's it that I cannot understand, nothing else. Perhaps somebody
teaches me the what and why about it. I am ready to learn.
And it is not the first time I stumble across such a radical cut:
In a former version of Kernel 2.6 Mplayer refused to work with Pinnsat
I quickly wrote an Email to Peter Hettkamp, the copyright owner of the
frontend cx24110. Within only two days (!!) he wrote a patch to fix that
I was very thankful towards him and very happy, but I still don't understand
who is responsible for doing such deep cuts. I still do not understand what
sense those deep cuts make. And I'd like to learn more and still more, and
I'd like to understand that what and why around that.
To make it ultimately clear excuse me please for setting up the following
Image you own a flat and I come by to hack down a carrying wall out of
whatever reason. And if you start asking why I'm doing this I keep very
cool, apologize for synchronization problems, for lack of time, for only
doing this in my spare time and whatever else. And then I continue with:
"Well, perhaps I come by in 3 months again, and perhaps I will rebuild your
flat then. But I ain't sure, that is why I say: Perhaps. Bye Bye!"
Now let me continue in my own words:
"Because I tried to overwork Edgar's material for 2.6.16-rc1-mm4. It is only
one line in the dvb-bt8xx-module, but this one line fucks up the whole
thing: PCTVSAT does not work."
One basic rule in the maintainers file says: Always test your changes,
however small, on at least 4 or 5 people, preferably many more.
I admit that for the first time I appeared taking part in Kernel development
I did not conform to that rule in any way. I overstepped this forum, because
Gerd Knorr told me that DVB maintainers were just moving and the patch
acceptance would take a lot of time for that reason. In so far I took the
direct way to AKPM at osdl.org. I overstepped the authority of big guru
Johannes Stezenbach (please smile now and feel yourself honored, Johannes!).
I regret that and have learnt that I did not do right. Sorry for that!
Running udev under Debian Sarge I did not manage how to suppress automatic
kernel module loading by a couple of debug parameters. So in my
documentation patch I dismissed the part describing the sense of those debug
parameters. But this part of Documentation also contained a whole lot of
orthographic junk and severe lacks as far as the contents was concerned.
At least Manu Abraham had an open ear for my concern and it's in an
acceptable state now. Great! And big thanks to him! But the question how to
suppress automatic module loading running udev is still open for me. Perhaps
someone will give me an answer.
Now this time I stuck very closely to that rule: Edgar Toernig claimed he
had tested this collection that you do not appreciate on several Twinhan
cards. And I tested this collection with an original Pinnacle PCTVSAT. So
what is wrong about a patch collection now that closes a hole that has been
ripped up by persons I do not know for reasons I do not know either and that
has been open for a quarter of a year now (what an immense amount of
time!!!). Tell me what is wrong about it. The fact that you do not like my
I'll wait for 2.6.16-rc2. And if I stumble again across that contaminating
code line or maybe several others found in 2.6.16-rc1-mm4, I'm gonna find it
out and publish it here in this forum, just to show my personal kind of
consequence, not only in verbal form but moreover in taking action and
establishing facts. OK??
"The changes in dvb_frontend.c have nothing to do with the rest."
Maybe. But the whole entity fulfilled its purpose: fixing a three months big
hole. And I appreciate progress exactly the other way round: Eliminating
redundant code is OK, but only if the continuity of the card support does
not take any harm: But what has happened was just such a deep hole in code
which caused a three month's breakdown.
And if there hadn't been Edgar Toernig's work I am goddam sure that this
breakdown would still continue, or am I wrong?
And I guess everybody will agree that this kind of procedure ain't no
progress, but simply the output of an idiotic strategy, or am I so wrong
thinking that? If one golden rule says: Test your stuff on 4 or 5 people
(see above), that does not mean and that will never mean: Destroy the whole
thing, tear anything down, and cause a breakdown lasting for months. That is
all I want to say. And this central point of my criticism has got nothing to
do with any reasons that anybody serves here: doing that stuff in my spare
time, synchronization problems, lack of time etc....... Nothing!
"Inspite of that Johannes tried to help you, didn't he .. ?"
Big error, Manu. As an opposite to your understanding of things Johannes
Stezenbach taught me several different lessons:
a. voluntary work causes a whole lot of frustration (an experience that I
personally share with him, and which is very often, but not always, caused
by a so-called fraction of passive consumers not ready to take anything or
any small part of work to be done in their own hands and instead of that
wasting other peoples time with bla-bla-bla-bla containing no substance)
b. unthankfulness is the leading rule in a world of bla-bla-blaers.
c. rubbing out coauthorship by rubbing out names of contributors is a matter
of lack of time and a matter of problems synchronizing CVS-DVB-Kernel and
kernel.org-stuff. Sarcastically said I am missing the words to express how
grateful I am to be taught this lesson by such a great guru whom I owe
utilities like szap.
Now how beautiful that in other parts of the kernel tree I find very noble
and polite requests on who personally wants himself to be added for whatever
kind of contribution. And I think this is exactly the way things should be.
In consequent opposition to my preceding experiences with big guru Johannes
Stezenbach I must state that I owe deep respect to three people:
a. Gerd Knorr
b. Peter Hettkamp
With both of them conversation and collaboration is not only big fun. It is
very constructive and bringing forward both participating human parts.
And at last I want to thank Andrew Morton who took himself a little time to
teach me the difference between a bad kernel patch on the one hand and a
professional and excellent one on the other.
Hope I eliminated at least a couple of misunderstandings spread around here
by people talking, praying to their guru, and getting only bad and wrong
things into a wrong neck.....
P. S. 1: Wouldn't it be a nice trait and a good effort if Johannes
Stezenbach himself would take a little time just to reflect the manner and
attitude in which he himself deals with hierarchies and practices
hierarchies in his daily life? I already apologized for my faults (see
above), so where is his part of doing better? I am waiting.......
And Mr. Endriss is topmost candidate number two for reflecting this kind of
questions....... Stop taking "we", just take "I", even if your user profile
at least seems to be a little bit vdr-formatted.....
P. S. 2.: I'm running latest xawtv-4.0 snapshot by Gerd Knorr in connection
with my Pinnsat card and Kernel 2.6.16-rc1. If there is any positive sense
in this 3 months of breakdown (which I still doubt), then it is the
In former kernels the relay of the card has been switched on by bttv
At least in some cases this fact caused unwanted warranty issues ( a fact I
proclaimed more than one time in another forum I was very engaged in, if not
to say which I brang up myself just to spread the acceptance of Linux and
make a small group of people at least aware that there is a bloody good
alternative towards the windoze mainstream in their minds.
New is that now not the bttv driver switches that relay, but the application
does in fact. This conforms to the standard the Pinnacle developers team
writing drivers for Windoze had already set in 2003. Late, but a real good
improvement! Thanks to all contributors!
Now what I am still missing is a small little tool to measure the signal
strength coming in through my dish. This tool should have an acoustic output
help tuning the dish for optimal input.
Question: Does anybody here know whether such a tool already exists?
Is it possible to program such a tool hardware-independent and adapt it to
the special needs of the specific card requirements?
The windoze driver kit from Pinnacle contains such a tool and I think it is
very helpful. The pity about it is that I cannot use this tiny little tool
anymore (also not in connection with wine), because a lot of time before
this day I decided to consequently quit using Windoze out of certain reasons
I'm sure you all know......
Linux is real big fun and I would like to improve and spread it wherever I
personally feel competent. So just tell me where and how I can help to get
necessary things done in order to bring things forward.
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
More information about the linux-dvb