v4l-utils: i2c-id.h and alevt

v4l-utils: i2c-id.h and alevt

[Hans Verkuil]

It's nice to see this new tree, that should be make it easier to develop
utilities!

After a quick check I noticed that the i2c-id.h header was copied from the
kernel. This is not necessary. The only utility that includes this is v4l2-dbg
and that one no longer needs it. Hans, can you remove this?

The second question is whether anyone would object if alevt is moved from
dvb-apps to v4l-utils? It is much more appropriate to have that tool in
v4l-utils.

Does anyone know of other unmaintained but useful tools that we might merge
into v4l-utils? E.g. xawtv perhaps?

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: v4l-utils: i2c-id.h and alevt

[hermann pitton]

Hi Hans, both,

Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
> It's nice to see this new tree, that should be make it easier to develop
> utilities!
> 
> After a quick check I noticed that the i2c-id.h header was copied from the
> kernel. This is not necessary. The only utility that includes this is v4l2-dbg
> and that one no longer needs it. Hans, can you remove this?
> 
> The second question is whether anyone would object if alevt is moved from
> dvb-apps to v4l-utils? It is much more appropriate to have that tool in
> v4l-utils.

i wonder that this stays such calm, hopefully a good sign.

In fact alevt analog should come with almost every distribution, but the
former alevt-dvb, named now only alevt, well, might be ok in some
future, is enhanced for doing also dvb-t-s and hence there ATM.

> Does anyone know of other unmaintained but useful tools that we might merge
> into v4l-utils? E.g. xawtv perhaps?

If for xawtv could be some more care, ships also since close to ever
with alevtd, that would be fine, but I'm not sure we are talking about
tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
example are also there and unmaintained.

Cheers,
Hermann

Re: v4l-utils: i2c-id.h and alevt

[Douglas Schilling Landgraf]

On 03/10/2010 02:04 AM, hermann pitton wrote:
> Hi Hans, both,
> 
> Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
>> It's nice to see this new tree, that should be make it easier to develop
>> utilities!
>>
>> After a quick check I noticed that the i2c-id.h header was copied from the
>> kernel. This is not necessary. The only utility that includes this is v4l2-dbg
>> and that one no longer needs it. Hans, can you remove this?
>>
>> The second question is whether anyone would object if alevt is moved from
>> dvb-apps to v4l-utils? It is much more appropriate to have that tool in
>> v4l-utils.
> 
> i wonder that this stays such calm, hopefully a good sign.
> 
> In fact alevt analog should come with almost every distribution, but the
> former alevt-dvb, named now only alevt, well, might be ok in some
> future, is enhanced for doing also dvb-t-s and hence there ATM.
> 
>> Does anyone know of other unmaintained but useful tools that we might merge
>> into v4l-utils? E.g. xawtv perhaps?
> 
> If for xawtv could be some more care, ships also since close to ever
> with alevtd, that would be fine, but I'm not sure we are talking about
> tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
> example are also there and unmaintained.
> 

I think would be nice to hear a word from Devin, which have been working in tvtime. Devin?

Cheers
Douglas

Re: v4l-utils: i2c-id.h and alevt

[Devin Heitmueller]

On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
<dougsland@gmail.com> wrote:
> On 03/10/2010 02:04 AM, hermann pitton wrote:
>> Hi Hans, both,
>>
>> Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
>>> It's nice to see this new tree, that should be make it easier to develop
>>> utilities!
>>>
>>> After a quick check I noticed that the i2c-id.h header was copied from the
>>> kernel. This is not necessary. The only utility that includes this is v4l2-dbg
>>> and that one no longer needs it. Hans, can you remove this?
>>>
>>> The second question is whether anyone would object if alevt is moved from
>>> dvb-apps to v4l-utils? It is much more appropriate to have that tool in
>>> v4l-utils.
>>
>> i wonder that this stays such calm, hopefully a good sign.
>>
>> In fact alevt analog should come with almost every distribution, but the
>> former alevt-dvb, named now only alevt, well, might be ok in some
>> future, is enhanced for doing also dvb-t-s and hence there ATM.
>>
>>> Does anyone know of other unmaintained but useful tools that we might merge
>>> into v4l-utils? E.g. xawtv perhaps?
>>
>> If for xawtv could be some more care, ships also since close to ever
>> with alevtd, that would be fine, but I'm not sure we are talking about
>> tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
>> example are also there and unmaintained.
>>
>
> I think would be nice to hear a word from Devin, which have been working in tvtime. Devin?

Sorry, I've been sick for the last couple of days and not actively on email.

I don't think it's a good idea to consolidate applications like xawtv
and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
nice because it's small and what the packages provides what it says it
does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
applications to be "utilities".

The apps in question are currently packaged by multiple distros today
as standalone packages.  Today distros can decide whether they want
the "bloat" associated with large GUI applications just to get the
benefits of a couple of command line utilities.  Bundling them
together makes that much harder (and would also result in a package
with lots of external dependencies on third party libraries).

Adding them into v4l2-utils doesn't really solve the real problem -
that there are very few people willing to put in the effort to
extend/improve these applications (something which, as Douglas pointed
out, I'm trying to improve in the case of tvtime).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: v4l-utils: i2c-id.h and alevt

[Hans Verkuil]

On Thursday 11 March 2010 15:31:32 Devin Heitmueller wrote:
> On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
> <dougsland@gmail.com> wrote:
> > On 03/10/2010 02:04 AM, hermann pitton wrote:
> >> Hi Hans, both,
> >>
> >> Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
> >>> It's nice to see this new tree, that should be make it easier to develop
> >>> utilities!
> >>>
> >>> After a quick check I noticed that the i2c-id.h header was copied from the
> >>> kernel. This is not necessary. The only utility that includes this is v4l2-dbg
> >>> and that one no longer needs it. Hans, can you remove this?
> >>>
> >>> The second question is whether anyone would object if alevt is moved from
> >>> dvb-apps to v4l-utils? It is much more appropriate to have that tool in
> >>> v4l-utils.
> >>
> >> i wonder that this stays such calm, hopefully a good sign.
> >>
> >> In fact alevt analog should come with almost every distribution, but the
> >> former alevt-dvb, named now only alevt, well, might be ok in some
> >> future, is enhanced for doing also dvb-t-s and hence there ATM.
> >>
> >>> Does anyone know of other unmaintained but useful tools that we might merge
> >>> into v4l-utils? E.g. xawtv perhaps?
> >>
> >> If for xawtv could be some more care, ships also since close to ever
> >> with alevtd, that would be fine, but I'm not sure we are talking about
> >> tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
> >> example are also there and unmaintained.
> >>
> >
> > I think would be nice to hear a word from Devin, which have been working in tvtime. Devin?
> 
> Sorry, I've been sick for the last couple of days and not actively on email.
> 
> I don't think it's a good idea to consolidate applications like xawtv
> and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
> nice because it's small and what the packages provides what it says it
> does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
> applications to be "utilities".
> 
> The apps in question are currently packaged by multiple distros today
> as standalone packages.  Today distros can decide whether they want
> the "bloat" associated with large GUI applications just to get the
> benefits of a couple of command line utilities.  Bundling them
> together makes that much harder (and would also result in a package
> with lots of external dependencies on third party libraries).
> 
> Adding them into v4l2-utils doesn't really solve the real problem -
> that there are very few people willing to put in the effort to
> extend/improve these applications (something which, as Douglas pointed
> out, I'm trying to improve in the case of tvtime).

For unmaintained applications the problem is that even those people that
have patches for them have no easy way to get them applied, precisely because
they are unmaintained.

We as v4l-dvb developers don't have the time to make TV apps, but perhaps if
we 'adopted' one unmaintained application and just update that whenever we
make new features, then that would be very helpful I think. Or perhaps just
provide a place for such applications where there is someone who can take
community supplied patches and review and apply them.

Such an application does not have to be in v4l2-utils, it can have its own
tree.

Anyway, regarding alevt: I believe that the consensus is that it should be
moved to v4l2-utils? Or am I wrong?

Regards,

	Hans


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: v4l-utils: i2c-id.h and alevt

[Devin Heitmueller]

On Fri, Mar 12, 2010 at 2:27 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> For unmaintained applications the problem is that even those people that
> have patches for them have no easy way to get them applied, precisely because
> they are unmaintained.
>
> We as v4l-dvb developers don't have the time to make TV apps, but perhaps if
> we 'adopted' one unmaintained application and just update that whenever we
> make new features, then that would be very helpful I think. Or perhaps just
> provide a place for such applications where there is someone who can take
> community supplied patches and review and apply them.

This is the key reason that KernelLabs "adopted" tvtime - the goal being to:

1.  Consolidate all the distro patches floating around
2.  Have a source tree that compiles without patches on modern distributions
3.  Have a channel for people to submit new patches
4.  Make improvements as necessary to make the app "just work" for
most modern tuner cards.

The goal is to get the distros to switch over to treating our tree as
the "official upstream source" so that people will finally have a
lightweight application for analog tv that "just works" and ships with
their Linux distro by default.

> Such an application does not have to be in v4l2-utils, it can have its own
> tree.

If the goal is for the LinuxTV group to adopt some of these
applications, I would definitely recommend it not be in the v4l-utils
tree (for reasons stated in the previous email).  that said, I
certainly have no objection to it in principle.

> Anyway, regarding alevt: I believe that the consensus is that it should be
> moved to v4l2-utils? Or am I wrong?

I haven't looked at the alevt code itself but I believe the answer
should be based on the following questions:

1.  How big is it?  Will distros not want to include the package by
default because along with a few KB of utilities they also end up with
several megabytes of crap that the vast majority of people don't care
about?

2.  What external dependencies does it have?  Right now, v4l-utils is
just a few command line tools with minimal dependencies (meaning it is
trivial to install in pretty much all environments, including those
without X11).  If the result is that you would now have to install
dozens of packages, then that would be a bad thing.

Jamming stuff into v4l-utils should not be seen as some sort of
backdoor way to get Linux distributions to include programs that they
wouldn't have otherwise.  The distributions should see real value in
the additional tool.  If they value the program, they will package the
program if we host it even as a standalone project outside of
v4l-utils.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: v4l-utils: i2c-id.h and alevt

[Hans de Goede]

Hi,

On 03/12/2010 08:27 AM, Hans Verkuil wrote:
> On Thursday 11 March 2010 15:31:32 Devin Heitmueller wrote:
>> On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
>> <dougsland@gmail.com>  wrote:
>>> On 03/10/2010 02:04 AM, hermann pitton wrote:
>>>> Hi Hans, both,
>>>>
>>>> Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
>>>>> It's nice to see this new tree, that should be make it easier to develop
>>>>> utilities!
>>>>>
>>>>> After a quick check I noticed that the i2c-id.h header was copied from the
>>>>> kernel. This is not necessary. The only utility that includes this is v4l2-dbg
>>>>> and that one no longer needs it. Hans, can you remove this?
>>>>>
>>>>> The second question is whether anyone would object if alevt is moved from
>>>>> dvb-apps to v4l-utils? It is much more appropriate to have that tool in
>>>>> v4l-utils.
>>>>
>>>> i wonder that this stays such calm, hopefully a good sign.
>>>>
>>>> In fact alevt analog should come with almost every distribution, but the
>>>> former alevt-dvb, named now only alevt, well, might be ok in some
>>>> future, is enhanced for doing also dvb-t-s and hence there ATM.
>>>>
>>>>> Does anyone know of other unmaintained but useful tools that we might merge
>>>>> into v4l-utils? E.g. xawtv perhaps?
>>>>
>>>> If for xawtv could be some more care, ships also since close to ever
>>>> with alevtd, that would be fine, but I'm not sure we are talking about
>>>> tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
>>>> example are also there and unmaintained.
>>>>
>>>
>>> I think would be nice to hear a word from Devin, which have been working in tvtime. Devin?
>>
>> Sorry, I've been sick for the last couple of days and not actively on email.
>>
>> I don't think it's a good idea to consolidate applications like xawtv
>> and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
>> nice because it's small and what the packages provides what it says it
>> does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
>> applications to be "utilities".
>>
>> The apps in question are currently packaged by multiple distros today
>> as standalone packages.  Today distros can decide whether they want
>> the "bloat" associated with large GUI applications just to get the
>> benefits of a couple of command line utilities.  Bundling them
>> together makes that much harder (and would also result in a package
>> with lots of external dependencies on third party libraries).
>>
>> Adding them into v4l2-utils doesn't really solve the real problem -
>> that there are very few people willing to put in the effort to
>> extend/improve these applications (something which, as Douglas pointed
>> out, I'm trying to improve in the case of tvtime).
>
> For unmaintained applications the problem is that even those people that
> have patches for them have no easy way to get them applied, precisely because
> they are unmaintained.
>
> We as v4l-dvb developers don't have the time to make TV apps, but perhaps if
> we 'adopted' one unmaintained application and just update that whenever we
> make new features, then that would be very helpful I think. Or perhaps just
> provide a place for such applications where there is someone who can take
> community supplied patches and review and apply them.
>
> Such an application does not have to be in v4l2-utils, it can have its own
> tree.
>
> Anyway, regarding alevt: I believe that the consensus is that it should be
> moved to v4l2-utils? Or am I wrong?
>

I'm not in favor of moving alevt into v4l-utils, if there are
people who want to pick up its maintenance and host a separate tree for
it at linuxtv.org including doing regular tarbal releases for upstream to consume
that would seem a good idea to me.

Regards,

Hans

Re: v4l-utils: i2c-id.h and alevt

[Hans de Goede]

Hi,

On 03/11/2010 03:31 PM, Devin Heitmueller wrote:
> On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
> <dougsland@gmail.com>  wrote:
>> On 03/10/2010 02:04 AM, hermann pitton wrote:
>>> Hi Hans, both,
>>>
>>> Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
>>>> It's nice to see this new tree, that should be make it easier to develop
>>>> utilities!
>>>>
>>>> After a quick check I noticed that the i2c-id.h header was copied from the
>>>> kernel. This is not necessary. The only utility that includes this is v4l2-dbg
>>>> and that one no longer needs it. Hans, can you remove this?
>>>>
>>>> The second question is whether anyone would object if alevt is moved from
>>>> dvb-apps to v4l-utils? It is much more appropriate to have that tool in
>>>> v4l-utils.
>>>
>>> i wonder that this stays such calm, hopefully a good sign.
>>>
>>> In fact alevt analog should come with almost every distribution, but the
>>> former alevt-dvb, named now only alevt, well, might be ok in some
>>> future, is enhanced for doing also dvb-t-s and hence there ATM.
>>>
>>>> Does anyone know of other unmaintained but useful tools that we might merge
>>>> into v4l-utils? E.g. xawtv perhaps?
>>>
>>> If for xawtv could be some more care, ships also since close to ever
>>> with alevtd, that would be fine, but I'm not sure we are talking about
>>> tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
>>> example are also there and unmaintained.
>>>
>>
>> I think would be nice to hear a word from Devin, which have been working in tvtime. Devin?
>
> Sorry, I've been sick for the last couple of days and not actively on email.
>
> I don't think it's a good idea to consolidate applications like xawtv
> and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
> nice because it's small and what the packages provides what it says it
> does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
> applications to be "utilities".
>
> The apps in question are currently packaged by multiple distros today
> as standalone packages.  Today distros can decide whether they want
> the "bloat" associated with large GUI applications just to get the
> benefits of a couple of command line utilities.  Bundling them
> together makes that much harder (and would also result in a package
> with lots of external dependencies on third party libraries).
>
> Adding them into v4l2-utils doesn't really solve the real problem -
> that there are very few people willing to put in the effort to
> extend/improve these applications (something which, as Douglas pointed
> out, I'm trying to improve in the case of tvtime).
>

Ack,

What would be good to do IMHO is decide for unmaintained apps like xawtv
and alevt if we want to adopt them and if we do, to create separate git
trees for them, and become a new upstream including doing regular
tarbals releases. Some time ago I did a lot of work on the Fedora xawtv
packages and I would be willing to pull such an effort for xawtv.

If we start doing this we really should start running some sort of
bugtracker on linuxtv.org btw, or ask if we can use bugzilla.kernel.org
for this.

Regards,

Hans

Re: v4l-utils: i2c-id.h and alevt

[Manu Abraham]

On Fri, Mar 12, 2010 at 7:40 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 03/11/2010 03:31 PM, Devin Heitmueller wrote:
>>
>> On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
>> <dougsland@gmail.com>  wrote:
>>>
>>> On 03/10/2010 02:04 AM, hermann pitton wrote:
>>>>
>>>> Hi Hans, both,
>>>>
>>>> Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
>>>>>
>>>>> It's nice to see this new tree, that should be make it easier to
>>>>> develop
>>>>> utilities!
>>>>>
>>>>> After a quick check I noticed that the i2c-id.h header was copied from
>>>>> the
>>>>> kernel. This is not necessary. The only utility that includes this is
>>>>> v4l2-dbg
>>>>> and that one no longer needs it. Hans, can you remove this?
>>>>>
>>>>> The second question is whether anyone would object if alevt is moved
>>>>> from
>>>>> dvb-apps to v4l-utils? It is much more appropriate to have that tool in
>>>>> v4l-utils.
>>>>
>>>> i wonder that this stays such calm, hopefully a good sign.
>>>>
>>>> In fact alevt analog should come with almost every distribution, but the
>>>> former alevt-dvb, named now only alevt, well, might be ok in some
>>>> future, is enhanced for doing also dvb-t-s and hence there ATM.
>>>>
>>>>> Does anyone know of other unmaintained but useful tools that we might
>>>>> merge
>>>>> into v4l-utils? E.g. xawtv perhaps?
>>>>
>>>> If for xawtv could be some more care, ships also since close to ever
>>>> with alevtd, that would be fine, but I'm not sure we are talking about
>>>> tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
>>>> example are also there and unmaintained.
>>>>
>>>
>>> I think would be nice to hear a word from Devin, which have been working
>>> in tvtime. Devin?
>>
>> Sorry, I've been sick for the last couple of days and not actively on
>> email.
>>
>> I don't think it's a good idea to consolidate applications like xawtv
>> and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
>> nice because it's small and what the packages provides what it says it
>> does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
>> applications to be "utilities".
>>
>> The apps in question are currently packaged by multiple distros today
>> as standalone packages.  Today distros can decide whether they want
>> the "bloat" associated with large GUI applications just to get the
>> benefits of a couple of command line utilities.  Bundling them
>> together makes that much harder (and would also result in a package
>> with lots of external dependencies on third party libraries).
>>
>> Adding them into v4l2-utils doesn't really solve the real problem -
>> that there are very few people willing to put in the effort to
>> extend/improve these applications (something which, as Douglas pointed
>> out, I'm trying to improve in the case of tvtime).
>>
>
> Ack,


ACK

> What would be good to do IMHO is decide for unmaintained apps like xawtv
> and alevt if we want to adopt them and if we do, to create separate git
> trees for them, and become a new upstream including doing regular
> tarbals releases. Some time ago I did a lot of work on the Fedora xawtv
> packages and I would be willing to pull such an effort for xawtv.


Simply creating a tree for an application doesn't really help. At
least it needs a "commitment" to that app to keep it updated. Unless,
someone really puts in such an effort, creating a tree doesn't really
help, it simplyt adds to the confusion for a normal user as to where
he should download his application for his distro, if such a package
doesn't exist.


Regards,
Manu

v4l-utils, dvb-utils, xawtv and alevt (was: v4l-utils: i2c-id.h and alevt)

[Chicken Shack]

Am Freitag, den 12.03.2010, 20:20 +0400 schrieb Manu Abraham:
> On Fri, Mar 12, 2010 at 7:40 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> > Hi,
> >
> > On 03/11/2010 03:31 PM, Devin Heitmueller wrote:
> >>
> >> On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
> >> <dougsland@gmail.com>  wrote:
> >>>
> >>> On 03/10/2010 02:04 AM, hermann pitton wrote:
> >>>>
> >>>> Hi Hans, both,
> >>>>
> >>>> Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
> >>>>>
> >>>>> It's nice to see this new tree, that should be make it easier to
> >>>>> develop
> >>>>> utilities!
> >>>>>
> >>>>> After a quick check I noticed that the i2c-id.h header was copied from
> >>>>> the
> >>>>> kernel. This is not necessary. The only utility that includes this is
> >>>>> v4l2-dbg
> >>>>> and that one no longer needs it. Hans, can you remove this?
> >>>>>
> >>>>> The second question is whether anyone would object if alevt is moved
> >>>>> from
> >>>>> dvb-apps to v4l-utils? It is much more appropriate to have that tool in
> >>>>> v4l-utils.
> >>>>
> >>>> i wonder that this stays such calm, hopefully a good sign.
> >>>>
> >>>> In fact alevt analog should come with almost every distribution, but the
> >>>> former alevt-dvb, named now only alevt, well, might be ok in some
> >>>> future, is enhanced for doing also dvb-t-s and hence there ATM.
> >>>>
> >>>>> Does anyone know of other unmaintained but useful tools that we might
> >>>>> merge
> >>>>> into v4l-utils? E.g. xawtv perhaps?
> >>>>
> >>>> If for xawtv could be some more care, ships also since close to ever
> >>>> with alevtd, that would be fine, but I'm not sure we are talking about
> >>>> tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
> >>>> example are also there and unmaintained.
> >>>>
> >>>
> >>> I think would be nice to hear a word from Devin, which have been working
> >>> in tvtime. Devin?
> >>
> >> Sorry, I've been sick for the last couple of days and not actively on
> >> email.
> >>
> >> I don't think it's a good idea to consolidate applications like xawtv
> >> and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
> >> nice because it's small and what the packages provides what it says it
> >> does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
> >> applications to be "utilities".
> >>
> >> The apps in question are currently packaged by multiple distros today
> >> as standalone packages.  Today distros can decide whether they want
> >> the "bloat" associated with large GUI applications just to get the
> >> benefits of a couple of command line utilities.  Bundling them
> >> together makes that much harder (and would also result in a package
> >> with lots of external dependencies on third party libraries).
> >>
> >> Adding them into v4l2-utils doesn't really solve the real problem -
> >> that there are very few people willing to put in the effort to
> >> extend/improve these applications (something which, as Douglas pointed
> >> out, I'm trying to improve in the case of tvtime).
> >>
> >
> > Ack,
> 
> 
> ACK
> 
> > What would be good to do IMHO is decide for unmaintained apps like xawtv
> > and alevt if we want to adopt them and if we do, to create separate git
> > trees for them, and become a new upstream including doing regular
> > tarbals releases. Some time ago I did a lot of work on the Fedora xawtv
> > packages and I would be willing to pull such an effort for xawtv.
> 
> 
> Simply creating a tree for an application doesn't really help. At
> least it needs a "commitment" to that app to keep it updated. Unless,
> someone really puts in such an effort, creating a tree doesn't really
> help, it simplyt adds to the confusion for a normal user as to where
> he should download his application for his distro, if such a package
> doesn't exist.
> 
> 
> Regards,
> Manu
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi people,

just my 1 Euro as contribution here:

Your merging hysteria and the resulting "discussion" is simply nonsense
IMHO.

In how far?

1. Alevt 1.7.0 is not just another tool, but it is instead a
self-contained videotext application consisting of three parts:
a. alevt, b. alevt-date c. alevt-cap

While the packed size of alevt is 78770 the complete size of the
dvb-apps as a whole ranges around 350000.

I am not against hosting this program at linuxtv.org, but if this
decision is made the decision should be an intelligent one: alevt is a
separate tree, and any other choice is simply a dumb one.
Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
only need the libc6.

2. Xawtv-4.0 pre is not usable as a whole. Thus you cannot treat it as a
whole. And that's exactly why you cannot discuss it as a whole!

The usable parts are:

a. mtt: a slave videotext application which is running independently
from the master application tuning the channels.
Its packed size amounts to 107744.

b. dvbrowse: a slave EPG application which is running independently from
the master application tuning the channels.
Packed Size: 101267.

c. dvbradio: a fast and rather stable running application for watching
DVB radio streams.
Packed Size: 119957.
Problem: dvbradio would need investigation to understand channel lists
in vdr channels.conf format.
As long as this is not the case, the insane slow homebrew scanner called
alexplore is necessary to produce a channels list.
Gerd implied some vdr modules into thew package, but they are
ca. unfinished work
cb. for debug purposes only


The unusable parts are:

a. xawtv itself, the main program.
It never ran stable and it is unfinished work.
Its graphical capabilities are pure rubbish compared to todays
standards.

b. Lots of aged tools like scantv or radio who just have survived
somehow but weren't modified.


Conclusions:

Alevt and mtt are videotext programs who are self-contained. They both
serve for analogue AND for DVB usage.
In so far the MA decision to merge alevt into dvb-apps was and still
remains idiotic.
The discussion to merge it into the v4l-utils isn't more intelligent
either.

You can maintain this discontinued stuff at linuxtv.org, but if you do
then please stop these completely insane merging activities.

Shall MA merge his vegetarian recipe pap in India - no problem!
But I do not want him to maintain software at linuxtv.org, no matter
what kind of software it may be.
We need reliable maintainers - not moody primadonna-would-like-tos!

Cheers

Uwe

Re: v4l-utils, dvb-utils, xawtv and alevt

[Hans de Goede]

Hi,

On 03/12/2010 08:10 PM, Chicken Shack wrote:
> 1. Alevt 1.7.0 is not just another tool, but it is instead a
> self-contained videotext application consisting of three parts:
> a. alevt, b. alevt-date c. alevt-cap
>
> While the packed size of alevt is 78770 the complete size of the
> dvb-apps as a whole ranges around 350000.
>
> I am not against hosting this program at linuxtv.org, but if this
> decision is made the decision should be an intelligent one: alevt is a
> separate tree, and any other choice is simply a dumb one.
> Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
> only need the libc6.
>

Seems we agree here, becoming a new upstream for alevt is good, merging
it into another package is not good :)

> 2. Xawtv-4.0 pre is not usable as a whole. Thus you cannot treat it as a
> whole. And that's exactly why you cannot discuss it as a whole!
>

Actually when I was talking about doing a tree to collect distro packages
and serve as a new upstream for xawtv I was talking about xawtv version
3.95, is that the same as which you call xawtv-4.0 pre ?



> The usable parts are:
>
> a. mtt: a slave videotext application which is running independently
> from the master application tuning the channels.
> Its packed size amounts to 107744.
>
> b. dvbrowse: a slave EPG application which is running independently from
> the master application tuning the channels.
> Packed Size: 101267.
>
> c. dvbradio: a fast and rather stable running application for watching
> DVB radio streams.
> Packed Size: 119957.
> Problem: dvbradio would need investigation to understand channel lists
> in vdr channels.conf format.
> As long as this is not the case, the insane slow homebrew scanner called
> alexplore is necessary to produce a channels list.
> Gerd implied some vdr modules into thew package, but they are
> ca. unfinished work
> cb. for debug purposes only
>
>
> The unusable parts are:
>
> a. xawtv itself, the main program.
> It never ran stable and it is unfinished work.
> Its graphical capabilities are pure rubbish compared to todays
> standards.
>

??

Its UI is not a brilliant piece of work but it is usable and certainly
is stable. Actually it still is my preffered app for tvcard testing / usage.

> b. Lots of aged tools like scantv or radio who just have survived
> somehow but weren't modified.
>

If these are really useless we could certainly drop them, as we could
drop say v4l-ctl once we've got rid of the last v4l1 drivers.

Regards,

Hans

Re: v4l-utils, dvb-utils, xawtv and alevt

[Chicken Shack]

Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede:
> Hi,
> 
> On 03/12/2010 08:10 PM, Chicken Shack wrote:
> > 1. Alevt 1.7.0 is not just another tool, but it is instead a
> > self-contained videotext application consisting of three parts:
> > a. alevt, b. alevt-date c. alevt-cap
> >
> > While the packed size of alevt is 78770 the complete size of the
> > dvb-apps as a whole ranges around 350000.
> >
> > I am not against hosting this program at linuxtv.org, but if this
> > decision is made the decision should be an intelligent one: alevt is a
> > separate tree, and any other choice is simply a dumb one.
> > Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
> > only need the libc6.

Good morning Hans,

> >
> 
> Seems we agree here, becoming a new upstream for alevt is good, merging
> it into another package is not good :)

Yeah, exactly, as we're NOT talking about just another 200-liner........

> > 2. Xawtv-4.0 pre is not usable as a whole. Thus you cannot treat it as a
> > whole. And that's exactly why you cannot discuss it as a whole!
> >
> 
> Actually when I was talking about doing a tree to collect distro packages
> and serve as a new upstream for xawtv I was talking about xawtv version
> 3.95, is that the same as which you call xawtv-4.0 pre ?

Definitely not.
3.95 is analogue only and thus is discontinued as version.
4.0 pre is the alpha-state tarball that you can get here:

http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz

Inofficial end of development somewhere in 2005 or 2006, last external
contribution from October 2008.

4.0 pre introduced DVB support for mtt (videotext) and the main program
xawtv.
It also introduced this disgusting slow channel scanner called alexplore
(DVB only) and dvbrowse as a complete new EPG solution for DVB only.
And it introduced dvbradio which would be excellent after some
investigation (-> learn to interpret channels.conf files).

> > The usable parts are:
> >
> > a. mtt: a slave videotext application which is running independently
> > from the master application tuning the channels.
> > Its packed size amounts to 107744.
> >
> > b. dvbrowse: a slave EPG application which is running independently from
> > the master application tuning the channels.
> > Packed Size: 101267.
> >
> > c. dvbradio: a fast and rather stable running application for watching
> > DVB radio streams.
> > Packed Size: 119957.
> > Problem: dvbradio would need investigation to understand channel lists
> > in vdr channels.conf format.
> > As long as this is not the case, the insane slow homebrew scanner called
> > alexplore is necessary to produce a channels list.
> > Gerd implied some vdr modules into thew package, but they are
> > ca. unfinished work
> > cb. for debug purposes only
> >
> >
> > The unusable parts are:
> >
> > a. xawtv itself, the main program.
> > It never ran stable and it is unfinished work.
> > Its graphical capabilities are pure rubbish compared to todays
> > standards.
> >
> 
> ??
> 
> Its UI is not a brilliant piece of work but it is usable and certainly
> is stable. Actually it still is my preffered app for tvcard testing / usage.

Hmmm. I'm not talking about the UI because I avoid discussions about
taste.
If you take a close critical look at the overlay capabilities you must
admit that they are technically reactionary. Not worth to be discussed
at all.
And I really do not know where the reason for the technical limitation
lies. Athena Widgets?
When I am looking TV through a monitor or modern flatscreen I expect a
full screen overlay picture covering the whole monitor's / sreen's size.
xawtv is not capable to offer that. Mplayer offers that f. ex.

The recording function of xawtv is tricky, while tvtime does not offer
any recording function. Thus it's not that easy to say: This one or that
one is best choice for testing / using.....

TVtime is the best compromise for analogue TV, Kaffeine is the best
compromise for DVB TV.
Note that I am stressing "compromise" - I do not say "choice".

> > b. Lots of aged tools like scantv or radio who just have survived
> > somehow but weren't modified.

> If these are really useless we could certainly drop them, as we could
> drop say v4l-ctl once we've got rid of the last v4l1 drivers.

Sure. There is also some obscure webcam tool for adressing USB webcams
via xawtv.
Streamer is exposed to be a quite flexible crossover recording tool for
command line usage, DVB and analogue.

Xawtv as main program runs stable as version 3.95 for analogue usage.
But I was not mentioning outdated analogue stuff.
Xawtv as main program runs highly unstable as version 4.0 pre for DVB
usage. Besides the overlay problem mentioned above I have had many
broken recordings due to its incomplete state.

> Regards,

> Hans

Best Regards

Uwe

Re: v4l-utils, dvb-utils, xawtv and alevt

[Hans de Goede]

Hi,

On 03/13/2010 11:15 AM, Chicken Shack wrote:
> Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede:
>> Hi,
>>
>> On 03/12/2010 08:10 PM, Chicken Shack wrote:
>>> 1. Alevt 1.7.0 is not just another tool, but it is instead a
>>> self-contained videotext application consisting of three parts:
>>> a. alevt, b. alevt-date c. alevt-cap
>>>
>>> While the packed size of alevt is 78770 the complete size of the
>>> dvb-apps as a whole ranges around 350000.
>>>
>>> I am not against hosting this program at linuxtv.org, but if this
>>> decision is made the decision should be an intelligent one: alevt is a
>>> separate tree, and any other choice is simply a dumb one.
>>> Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
>>> only need the libc6.
>
> Good morning Hans,
>

Good afternoon :)

> Definitely not.
> 3.95 is analogue only and thus is discontinued as version.
> 4.0 pre is the alpha-state tarball that you can get here:
>

Ah, ok. Well I must honestly say I've no interest in that I'm doing
package maintenance for the 3.95 release in Fedora and I know it
needs a lot of patching, AFAIK other distros are doing the same,
so it would be good to have / become a new upstream for xawtv 3.95,
to have a place to gather all the distro patches mostly and release
that, and where new patches if needed can accumulate and new
releases can be done from.


> http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz
>
> Inofficial end of development somewhere in 2005 or 2006, last external
> contribution from October 2008.
>
> 4.0 pre introduced DVB support for mtt (videotext) and the main program
> xawtv.
> It also introduced this disgusting slow channel scanner called alexplore
> (DVB only) and dvbrowse as a complete new EPG solution for DVB only.
> And it introduced dvbradio which would be excellent after some
> investigation (->  learn to interpret channels.conf files).
>

I see, well if there is an interest in bits of the 4.0 code base, then
grabbing those bits and having a tree with them and doing regular
tarbal releases for distro's to consume might be in interesting project
for some one. I would like to advocate to not call this xawtv, as AFAIK
all distros are still shipping 3.95, and as you said the xawtv part of 4.0
is broken so likely would not be included, at which point it
would be good to no longer call the resulting project xawtv.

Regards,

Hans

Re: v4l-utils, dvb-utils, xawtv and alevt

[Chicken Shack]

Am Samstag, den 13.03.2010, 13:34 +0100 schrieb Hans de Goede:
> Hi,
> 
> On 03/13/2010 11:15 AM, Chicken Shack wrote:
> > Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede:
> >> Hi,
> >>
> >> On 03/12/2010 08:10 PM, Chicken Shack wrote:
> >>> 1. Alevt 1.7.0 is not just another tool, but it is instead a
> >>> self-contained videotext application consisting of three parts:
> >>> a. alevt, b. alevt-date c. alevt-cap
> >>>
> >>> While the packed size of alevt is 78770 the complete size of the
> >>> dvb-apps as a whole ranges around 350000.
> >>>
> >>> I am not against hosting this program at linuxtv.org, but if this
> >>> decision is made the decision should be an intelligent one: alevt is a
> >>> separate tree, and any other choice is simply a dumb one.
> >>> Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
> >>> only need the libc6.
> >
> > Good morning Hans,
> >
> 
> Good afternoon :)
> 
> > Definitely not.
> > 3.95 is analogue only and thus is discontinued as version.
> > 4.0 pre is the alpha-state tarball that you can get here:
> >
> 
> Ah, ok. Well I must honestly say I've no interest in that I'm doing
> package maintenance for the 3.95 release in Fedora and I know it
> needs a lot of patching, AFAIK other distros are doing the same,
> so it would be good to have / become a new upstream for xawtv 3.95,
> to have a place to gather all the distro patches mostly and release
> that, and where new patches if needed can accumulate and new
> releases can be done from.
> 
> 
> > http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz
> >
> > Inofficial end of development somewhere in 2005 or 2006, last external
> > contribution from October 2008.
> >
> > 4.0 pre introduced DVB support for mtt (videotext) and the main program
> > xawtv.
> > It also introduced this disgusting slow channel scanner called alexplore
> > (DVB only) and dvbrowse as a complete new EPG solution for DVB only.
> > And it introduced dvbradio which would be excellent after some
> > investigation (->  learn to interpret channels.conf files).
> >
> 
> I see, well if there is an interest in bits of the 4.0 code base, then
> grabbing those bits and having a tree with them and doing regular
> tarbal releases for distro's to consume might be in interesting project
> for some one. I would like to advocate to not call this xawtv, as AFAIK
> all distros are still shipping 3.95, and as you said the xawtv part of 4.0
> is broken so likely would not be included, at which point it
> would be good to no longer call the resulting project xawtv.
> 
> Regards,
> 
> Hans
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Good afternoon Hans :)

"and as you said the xawtv part of 4.0 is broken so likely would not be
included, at which point it would be good to no longer call the
resulting project xawtv."

Pooh! Guess you got me wrong again.....

You can watch TV with xawtv 4.0 pre in analogue mode.
But if you want to record a film parallely you need
to execute streamer on the command line, as the graphical support
for starting the recording session will not work at all.

In DVB mode parallel tasking works.
The fact that I had many broken recordings can also be due to a
former bad kernel / bad DVB driver. This happened years ago and
thus I lost interest in xawtv as a common.
In the meantime the kernel drivers have become more mature and
I do not work with the same DVB card any longer.
Got a better card now and better drivers (Flexcop Technisat).
In spite of all changes the overlay capabilities of xawtv still remain a mess.

There should be a separate tree for alevt plus one separate tree called
"hybrid tools" combining all the orphaned software that does not fit into the
200-liner-scheme of v4l-utils and / or dvb-utils.

Linuxtv.org should not be a cemetery for orphaned software and it shouldn't
be reduced to a highly specialized milk farm for kernel drivers only where
the cows go "Mauro, please pull...".

There should be enough appropriate people to establish a functionable service
mode in which discussed issues also are being put into practice.....

Cheers

Uwe

Re: v4l-utils, dvb-utils, xawtv and alevt

[hermann pitton]

Am Samstag, den 13.03.2010, 14:43 +0100 schrieb Chicken Shack:
> Am Samstag, den 13.03.2010, 13:34 +0100 schrieb Hans de Goede:
> > Hi,
> > 
> > On 03/13/2010 11:15 AM, Chicken Shack wrote:
> > > Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede:
> > >> Hi,
> > >>
> > >> On 03/12/2010 08:10 PM, Chicken Shack wrote:
> > >>> 1. Alevt 1.7.0 is not just another tool, but it is instead a
> > >>> self-contained videotext application consisting of three parts:
> > >>> a. alevt, b. alevt-date c. alevt-cap
> > >>>
> > >>> While the packed size of alevt is 78770 the complete size of the
> > >>> dvb-apps as a whole ranges around 350000.
> > >>>
> > >>> I am not against hosting this program at linuxtv.org, but if this
> > >>> decision is made the decision should be an intelligent one: alevt is a
> > >>> separate tree, and any other choice is simply a dumb one.
> > >>> Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
> > >>> only need the libc6.

More clever would have been never to rename it from alevt-dvb to alevt.
On the prior you don't have any rights and I seriously doubt you have
any on the later.

> > > Good morning Hans,
> > >
> > 
> > Good afternoon :)
> > 
> > > Definitely not.
> > > 3.95 is analogue only and thus is discontinued as version.
> > > 4.0 pre is the alpha-state tarball that you can get here:

No, 3.95 is "official" and right for patching and 4x was never released.

I pointed to mpeg4ip only as a joke.

> > Ah, ok. Well I must honestly say I've no interest in that I'm doing
> > package maintenance for the 3.95 release in Fedora and I know it
> > needs a lot of patching, AFAIK other distros are doing the same,
> > so it would be good to have / become a new upstream for xawtv 3.95,
> > to have a place to gather all the distro patches mostly and release
> > that, and where new patches if needed can accumulate and new
> > releases can be done from.
> > 
> > 
> > > http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz
> > >
> > > Inofficial end of development somewhere in 2005 or 2006, last external
> > > contribution from October 2008.

It was on March 08 2005. You even don't know that?

http://linux.bytesex.org/v4l2/maintainer.txt

Maybe improve your Pinnacle stuff first, I can point you to a lot on the
TODO list.

Hermann

Re: v4l-utils, dvb-utils, xawtv and alevt

[Chicken Shack]

Am Sonntag, den 14.03.2010, 06:39 +0100 schrieb hermann pitton:
> Am Samstag, den 13.03.2010, 14:43 +0100 schrieb Chicken Shack:
> > Am Samstag, den 13.03.2010, 13:34 +0100 schrieb Hans de Goede:
> > > Hi,
> > > 
> > > On 03/13/2010 11:15 AM, Chicken Shack wrote:
> > > > Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede:
> > > >> Hi,
> > > >>
> > > >> On 03/12/2010 08:10 PM, Chicken Shack wrote:
> > > >>> 1. Alevt 1.7.0 is not just another tool, but it is instead a
> > > >>> self-contained videotext application consisting of three parts:
> > > >>> a. alevt, b. alevt-date c. alevt-cap
> > > >>>
> > > >>> While the packed size of alevt is 78770 the complete size of the
> > > >>> dvb-apps as a whole ranges around 350000.
> > > >>>
> > > >>> I am not against hosting this program at linuxtv.org, but if this
> > > >>> decision is made the decision should be an intelligent one: alevt is a
> > > >>> separate tree, and any other choice is simply a dumb one.
> > > >>> Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
> > > >>> only need the libc6.
> 
> More clever would have been never to rename it from alevt-dvb to alevt.
> On the prior you don't have any rights and I seriously doubt you have
> any on the later.

Only a pure brainless idiot who understands less than nothing can rant
crap like this.....

Typical Pitton, typical no-brain quality....

> 
> > > > Good morning Hans,
> > > >
> > > 
> > > Good afternoon :)
> > > 
> > > > Definitely not.
> > > > 3.95 is analogue only and thus is discontinued as version.
> > > > 4.0 pre is the alpha-state tarball that you can get here:
> 
> No, 3.95 is "official" and right for patching and 4x was never released.

See above.....

> I pointed to mpeg4ip only as a joke.
> 
> > > Ah, ok. Well I must honestly say I've no interest in that I'm doing
> > > package maintenance for the 3.95 release in Fedora and I know it
> > > needs a lot of patching, AFAIK other distros are doing the same,
> > > so it would be good to have / become a new upstream for xawtv 3.95,
> > > to have a place to gather all the distro patches mostly and release
> > > that, and where new patches if needed can accumulate and new
> > > releases can be done from.
> > > 
> > > 
> > > > http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz
> > > >
> > > > Inofficial end of development somewhere in 2005 or 2006, last external
> > > > contribution from October 2008.
> 
> It was on March 08 2005. You even don't know that?

Completely irrelevant, stupid moron!

> http://linux.bytesex.org/v4l2/maintainer.txt
> 
> Maybe improve your Pinnacle stuff first, I can point you to a lot on the
> TODO list.

Don't owe no Pinnacle any longer for years now.

I personally took part in flexcop development as well-informed people
know.
That's a good driver now, and Patrick is someone you can really work
with, not unproblematic, but OK so far.
He's no Abraham, and he's no Pitton....


There's one thing I would really like to know:
Is there one example where your personal dumb rant was really helpful?

As the alevt example showed you're even too dumb to test a simple
application.
Where is your quality, where is your positive usable substance please?

I do not see any. I never saw any. Whenever I read your postings I am
very close to vomit because of the enormous amount of emptyness and
thickness speaking between the lines.
So why don't you simply fuck off, consume your alcohol / drugs elsewhere
and stay away from here? No one needs you, no one will be missing you
stinking brainless moron.

Dumb rant, pure no-brained dumbness and hostility - that's everything
connected with the name "Hermann Pitton".
Even ordinary trolls are more agreeable than you will ever be....

Aw: Re: v4l-utils, dvb-utils, xawtv and alevt

[hermann-pitton]

 


----- Original Nachricht ----
Von:     Chicken Shack <chicken.shack@gmx.de>
An:      hermann pitton <hermann-pitton@arcor.de>
Datum:   14.03.2010 12:13
Betreff: Re: v4l-utils, dvb-utils, xawtv and alevt

> Am Sonntag, den 14.03.2010, 06:39 +0100 schrieb hermann pitton:
> > Am Samstag, den 13.03.2010, 14:43 +0100 schrieb Chicken Shack:
> > > Am Samstag, den 13.03.2010, 13:34 +0100 schrieb Hans de Goede:
> > > > Hi,
> > > > 
> > > > On 03/13/2010 11:15 AM, Chicken Shack wrote:
> > > > > Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede:
> > > > >> Hi,
> > > > >>
> > > > >> On 03/12/2010 08:10 PM, Chicken Shack wrote:
> > > > >>> 1. Alevt 1.7.0 is not just another tool, but it is instead a
> > > > >>> self-contained videotext application consisting of three parts:
> > > > >>> a. alevt, b. alevt-date c. alevt-cap
> > > > >>>
> > > > >>> While the packed size of alevt is 78770 the complete size of the
> > > > >>> dvb-apps as a whole ranges around 350000.
> > > > >>>
> > > > >>> I am not against hosting this program at linuxtv.org, but if this
> > > > >>> decision is made the decision should be an intelligent one: alevt
> is a
> > > > >>> separate tree, and any other choice is simply a dumb one.
> > > > >>> Alevt-1.7.0 needs a lot of external dependencies, while the
> dvb-apps
> > > > >>> only need the libc6.
> > 
> > More clever would have been never to rename it from alevt-dvb to alevt.
> > On the prior you don't have any rights and I seriously doubt you have
> > any on the later.
> 
> Only a pure brainless idiot who understands less than nothing can rant
> crap like this.....
> 
> Typical Pitton, typical no-brain quality....
> 
> > 
> > > > > Good morning Hans,
> > > > >
> > > > 
> > > > Good afternoon :)
> > > > 
> > > > > Definitely not.
> > > > > 3.95 is analogue only and thus is discontinued as version.
> > > > > 4.0 pre is the alpha-state tarball that you can get here:
> > 
> > No, 3.95 is "official" and right for patching and 4x was never released.
> 
> See above.....
> 
> > I pointed to mpeg4ip only as a joke.
> > 
> > > > Ah, ok. Well I must honestly say I've no interest in that I'm doing
> > > > package maintenance for the 3.95 release in Fedora and I know it
> > > > needs a lot of patching, AFAIK other distros are doing the same,
> > > > so it would be good to have / become a new upstream for xawtv 3.95,
> > > > to have a place to gather all the distro patches mostly and release
> > > > that, and where new patches if needed can accumulate and new
> > > > releases can be done from.
> > > > 
> > > > 
> > > > > http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz
> > > > >
> > > > > Inofficial end of development somewhere in 2005 or 2006, last
> external
> > > > > contribution from October 2008.
> > 
> > It was on March 08 2005. You even don't know that?
> 
> Completely irrelevant, stupid moron!
> 
> > http://linux.bytesex.org/v4l2/maintainer.txt
> > 
> > Maybe improve your Pinnacle stuff first, I can point you to a lot on the
> > TODO list.
> 
> Don't owe no Pinnacle any longer for years now.
> 
> I personally took part in flexcop development as well-informed people
> know.
> That's a good driver now, and Patrick is someone you can really work
> with, not unproblematic, but OK so far.
> He's no Abraham, and he's no Pitton....
>

http://www.mail-archive.com/linux-dvb@linuxtv.org/msg23780.html

There is not any progress with you and likely never will be.

Cheers,
Hermann
 


Topp oder Hopp? Tolle Figur, scharfes Dekolleté oder sehenswertes Tatoo?! Bewerten Sie die besten Bilder und zeigen Sie auch selbst, was Sie haben! Jetzt reinklicken und mitmachen: http://www.arcor.de/rd/footer.toh

Re: v4l-utils: i2c-id.h and alevt

[Hans de Goede]

Hi,

On 03/11/2010 03:14 PM, Douglas Schilling Landgraf wrote:
> On 03/10/2010 02:04 AM, hermann pitton wrote:
>> Hi Hans, both,
>>
>> Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
>>> It's nice to see this new tree, that should be make it easier to develop
>>> utilities!
>>>
>>> After a quick check I noticed that the i2c-id.h header was copied from the
>>> kernel. This is not necessary. The only utility that includes this is v4l2-dbg
>>> and that one no longer needs it. Hans, can you remove this?
>>>


I somehow missed the original mail from Hans Verkuil here, so I'm replying here,
sorry for messing up the threading.

Fixed!

Regards,

Hans