[ANNOUNCE] git tree repositories

[ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Hi,

Today, a step to the future was given, in order to help developers to better
do their work: the addition of -git support at linuxtv.org server.

This is one idea that is being recurrent along the last years: to start using -git
as our primary resource for managing the patches at the development[1].

At the beginning, the usage CVS for of a SCM (Source Code Management) were
choosen on V4L/DVB. Both of the original V4L and DVB trees were developed with the 
help of cvs. On that time, upstream Linux kernel used to have another tree (BitKeeper).

In 2005, both V4L and DVB trees got merged into one cvs repository, and we've
discussed about what would be the better SCM solution. We've discussed more
about using svn, hg and git. On that time, both hg and git were new technologies,
based on the concept of a distributed SCM, where you don't need to go to the
server every time you're doing a command at the SCM.

Yet, Mercurial were more stable and used, while -git were giving his first
steps[2], being used almost only by the Linux Kernel, and several distros didn't use
to package it. Git objects were stored uncompressed, generating very large
trees. Also, -git tools were complex to use, and some "porcelain" packages were
needed, in order to be used by a normal user.

So, the decision was made to use mercurial. However, as time goes by, -git got much
more eyes than any other SCM, having all their weakness solved, and being developed
really fast. Also, it got adopted by several other projects, due to its capability 
and its number of features.

Technically speaking, -git is currently the most advanced distributed open-source
SCM application I know.

Yet, Mercurial has been doing a very good job maintaining the V4L/DVB trees, and, except
for a few points, it does the job.

However, the entire Linux Kernel development happens around -git. Even the ones that
were adopting other tools (like -alsa, that used to have also Mercurial repositories)
migrated to -git.

Despite all technical advantages, the rationale for the migration is quite simple: 
converting patches between different repositories and SCM tools cause development 
and merge delays, may cause patch mangling and eats lot of the time for people 
that are part of the process.

Also, every time a patch needs to touch on files outside the incomplete tree
used at the subsystem, an workaround need to be done, in order to avoid troubles 
and to be able to send the patch upstream.

So, it is simpler to just use -git.

Due to all the above reasons, I took some time to add -git support at linuxtv servers.
Both http and git methods to retrieve trees were enabled.

The new trees will be available at:
	http://linuxtv.org/git/

The merge tree, where all submitted patches will be merged, before sending upstream is:
	http://linuxtv.org/git?p=v4l-dvb.git;a=summary

This tree is basically a clone of Linus tree, so it runs the latest development kernel.
It is also (almost) in sync with our -hg tree (needing just a few adjustments).

The above tree will never be rebased, so it should be safe to use it for development.

I'll basically merge there all patches I receive. It is OK to submit patches against -hg,
since I can still run my old conversion stripts to convert them to -git. However, as
the conversion script is not fast (it takes between 15-30 secs to convert a single patch
to -git, since it needs to re-generate the entire tree with v4l/scripts/gentree.pl, for
ever patch), I kindly ask you to prefer submit me patches directly to -git.

With respect to the -hg tree with the out-of-tree building system, We really want to 
keep having a way to allow running the drivers with kernels other than the latest -rc 
one, for both development and testing.

As you all know, the number of drivers and the average number of merges per day is being
increasing, among with more complexity on some drivers that also touches arch and other
files outside drivers/media tree. Due to that, lots of my current time is devoted to keep
-hg and -git in sync, distracting me from my develoment and maintanership tasks to do it.
So, I simply don't have more time to keep maintaining both -hg and -git.

Due to that, I'm delegating the task of keeping -hg in sync with upstream and backporting
patches to run on older kernels to another person: Douglas has offered his help to keep 
the tree synchronized with the -git tree, and to add backport support. 

He already started doing that, fixing some incompatibility troubles between some drivers
and older kernels.

In terms of the out-of-tree building system evolution (e. g. the building system concept
behind the -hg tree), If people think it is worthy enough, maybe later this could also 
be converted also to -git, but preserving the building system and the backport patches. 
Another alternative would be to split the building systems and the backport patches, 
and apply them into the drivers/media files. Alsa subsystem does something like that. 
It may also be maintained as-is. So, suggestions are welcome about if and how can we improve 
the out-of-tree building.

Some details about the -git repositories still need to be defined, and I'll be sending
the instructions on how to use the repository management tools available at linuxtv site
to the developers, but the basic infrastructure is already there.

We also need to do more tests with the -git support, in order to be sure that it will
work as expected, and that it won't be eating much bandwidth or disk space.

In particular, for those who want to test the git, please clone first from kernel.org, and
then add a remote branch pointing to linuxtv.org. This helps to save our bandwidth.

The instructions on how to do it are in the top of the git page (http://linuxtv.org/git).

Thanks!
Mauro

---

[1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg12676.html
[2] http://en.wikipedia.org/wiki/Git_(software)

Re: [ANNOUNCE] git tree repositories

[Hans Verkuil]

On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote:
> Hi,
> 
> Today, a step to the future was given, in order to help developers to better
> do their work: the addition of -git support at linuxtv.org server.
> 
> This is one idea that is being recurrent along the last years: to start using -git
> as our primary resource for managing the patches at the development[1].
> 
> At the beginning, the usage CVS for of a SCM (Source Code Management) were
> choosen on V4L/DVB. Both of the original V4L and DVB trees were developed with the 
> help of cvs. On that time, upstream Linux kernel used to have another tree (BitKeeper).
> 
> In 2005, both V4L and DVB trees got merged into one cvs repository, and we've
> discussed about what would be the better SCM solution. We've discussed more
> about using svn, hg and git. On that time, both hg and git were new technologies,
> based on the concept of a distributed SCM, where you don't need to go to the
> server every time you're doing a command at the SCM.
> 
> Yet, Mercurial were more stable and used, while -git were giving his first
> steps[2], being used almost only by the Linux Kernel, and several distros didn't use
> to package it. Git objects were stored uncompressed, generating very large
> trees. Also, -git tools were complex to use, and some "porcelain" packages were
> needed, in order to be used by a normal user.
> 
> So, the decision was made to use mercurial. However, as time goes by, -git got much
> more eyes than any other SCM, having all their weakness solved, and being developed
> really fast. Also, it got adopted by several other projects, due to its capability 
> and its number of features.
> 
> Technically speaking, -git is currently the most advanced distributed open-source
> SCM application I know.
> 
> Yet, Mercurial has been doing a very good job maintaining the V4L/DVB trees, and, except
> for a few points, it does the job.
> 
> However, the entire Linux Kernel development happens around -git. Even the ones that
> were adopting other tools (like -alsa, that used to have also Mercurial repositories)
> migrated to -git.
> 
> Despite all technical advantages, the rationale for the migration is quite simple: 
> converting patches between different repositories and SCM tools cause development 
> and merge delays, may cause patch mangling and eats lot of the time for people 
> that are part of the process.
> 
> Also, every time a patch needs to touch on files outside the incomplete tree
> used at the subsystem, an workaround need to be done, in order to avoid troubles 
> and to be able to send the patch upstream.
> 
> So, it is simpler to just use -git.
> 
> Due to all the above reasons, I took some time to add -git support at linuxtv servers.
> Both http and git methods to retrieve trees were enabled.
> 
> The new trees will be available at:
> 	http://linuxtv.org/git/
> 
> The merge tree, where all submitted patches will be merged, before sending upstream is:
> 	http://linuxtv.org/git?p=v4l-dvb.git;a=summary
> 
> This tree is basically a clone of Linus tree, so it runs the latest development kernel.
> It is also (almost) in sync with our -hg tree (needing just a few adjustments).
> 
> The above tree will never be rebased, so it should be safe to use it for development.
> 
> I'll basically merge there all patches I receive. It is OK to submit patches against -hg,
> since I can still run my old conversion stripts to convert them to -git. However, as
> the conversion script is not fast (it takes between 15-30 secs to convert a single patch
> to -git, since it needs to re-generate the entire tree with v4l/scripts/gentree.pl, for
> ever patch), I kindly ask you to prefer submit me patches directly to -git.
> 
> With respect to the -hg tree with the out-of-tree building system, We really want to 
> keep having a way to allow running the drivers with kernels other than the latest -rc 
> one, for both development and testing.
> 
> As you all know, the number of drivers and the average number of merges per day is being
> increasing, among with more complexity on some drivers that also touches arch and other
> files outside drivers/media tree. Due to that, lots of my current time is devoted to keep
> -hg and -git in sync, distracting me from my develoment and maintanership tasks to do it.
> So, I simply don't have more time to keep maintaining both -hg and -git.
> 
> Due to that, I'm delegating the task of keeping -hg in sync with upstream and backporting
> patches to run on older kernels to another person: Douglas has offered his help to keep 
> the tree synchronized with the -git tree, and to add backport support. 
> 
> He already started doing that, fixing some incompatibility troubles between some drivers
> and older kernels.

Mauro, I just wanted to thank you for doing all the hard work in moving to git!

And a big 'thank you' to Douglas as well for taking over hg maintenance!

I do have one proposal: parts of our hg tree are independent of git: v4l2-apps,
possibly some firmware build code (not 100% sure of that), v4l_experimental,
perhaps some documentation stuff. My proposal is that we make a separate hg
or git tree for those. It will make it easier to package by distros and it makes it
easier to maintain v4l2-apps et al as well. It might even simplify Douglas's work
by moving non-essential code out of the compat hg tree.

I'll be updating my daily build scripts to start using git soon (I'll keep using
hg for the older kernels of course).

> In terms of the out-of-tree building system evolution (e. g. the building system concept
> behind the -hg tree), If people think it is worthy enough, maybe later this could also 
> be converted also to -git, but preserving the building system and the backport patches. 
> Another alternative would be to split the building systems and the backport patches, 
> and apply them into the drivers/media files. Alsa subsystem does something like that. 
> It may also be maintained as-is. So, suggestions are welcome about if and how can we improve 
> the out-of-tree building.
> 
> Some details about the -git repositories still need to be defined, and I'll be sending
> the instructions on how to use the repository management tools available at linuxtv site
> to the developers, but the basic infrastructure is already there.
> 
> We also need to do more tests with the -git support, in order to be sure that it will
> work as expected, and that it won't be eating much bandwidth or disk space.
> 
> In particular, for those who want to test the git, please clone first from kernel.org, and
> then add a remote branch pointing to linuxtv.org. This helps to save our bandwidth.
> 
> The instructions on how to do it are in the top of the git page (http://linuxtv.org/git).

Regards,

	Hans

> 
> Thanks!
> Mauro
> 
> ---
> 
> [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg12676.html
> [2] http://en.wikipedia.org/wiki/Git_(software)
> --
> 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
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: [ANNOUNCE] git tree repositories

[Laurent Pinchart]

Hi Mauro,

I would like to personally thank you for spending time on git support at 
linuxtv.org. Git support was a long-awaited feature for many developers (and I 
certainly was one of them).

All the work done behind the scene on linuxtv.org isn't seen by end-users and 
can thus be less rewarding than working on the code. However, it's of critical 
importance to make the development process as smooth as possible. For that 
reason, thank you again.

Thanks to Douglas too for agreeing to manage backports. Getting the latest 
version of our drivers working on older kernels make the test base much 
larger, leading to better quality code (or at least to more bug reports :-)).

-- 
Regards,

Laurent Pinchart

Re: [ANNOUNCE] git tree repositories

[Patrick Boettcher]

On Tuesday 19 January 2010 08:53:10 Hans Verkuil wrote:
> On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote:
> >
> > He already started doing that, fixing some incompatibility troubles
> > between some drivers and older kernels.
> 
> Mauro, I just wanted to thank you for doing all the hard work in moving to
>  git!
> 
> And a big 'thank you' to Douglas as well for taking over hg maintenance!

A big thank you also from me. 

This is really outstanding work you're doing there and it's highly 
appreciated.


> I do have one proposal: parts of our hg tree are independent of git:
>  v4l2-apps, possibly some firmware build code (not 100% sure of that),
>  v4l_experimental, perhaps some documentation stuff. My proposal is that we
>  make a separate hg or git tree for those. It will make it easier to
>  package by distros and it makes it easier to maintain v4l2-apps et al as
>  well. It might even simplify Douglas's work by moving non-essential code
>  out of the compat hg tree.
> 
> > In terms of the out-of-tree building system evolution (e. g. the building
> > system concept behind the -hg tree), If people think it is worthy enough,
> > maybe later this could also be converted also to -git, but preserving the
> > building system and the backport patches. Another alternative would be to
> > split the building systems and the backport patches, and apply them into
> > the drivers/media files.

I'm strongly in need of a build-only-v4l-dvb build system. Because I'm most of 
the time using distro-kernels in my productive environments and I'm replacing 
v4l/dvb drivers with the one from v4l-dvb.

One step into the direction of a solution might be:
Why not including the v4l-dvb/v4l/Makefile and the related files into that 
separate repository Hans is describing here and then telling 'make' to make 
links to ../../v4l-dvb/ instead of ../linux as of today.

But I don't know how to solve the ifdef KERNEL_VERSION for having backward 
compatibility in the source files. Maybe with a patch for each kernel version?

BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to 
mention right now, that one big difference to HG in the way we have used it, is 
that one developer now can do all the work only with one clone of v4l-dvb and 
using branches for each development.

best regards,
-- 
Patrick Boettcher - KernelLabs
http://www.kernellabs.com/

Re: [ANNOUNCE] git tree repositories

[Devin Heitmueller]

Hello Mauro,

I find it somewhat unfortunate that this is labeled "ANNOUNCE" instead
of "RFC".  It shows how little you care about soliciting the opinions
of the other developers.  Rather than making a proposal for how the
process can be improved and soliciting feedback, you have chosen to
decide for all of us what the best approach is and how all of us will
develop in the future.

I know you'll continue to receive alot of "thank you" and ""great job"
comments from some of the developers who have been pushing for this,
so I'll be the "bad guy" and point out the downsides to what you are
proposing.

First off, I would like to note that I have absolutely no problem with
git.  I think it's a great tool and I use it for other projects.  If
the question today was "which source control software to use", I have
no doubt I would choose git over mercurial.  I've used a variety of
different source control systems both open source and commercial, and
git is a really good tool.

That said, my real problem is with the change requiring all the active
developers to be developing on the latest Linux kernel.

Before I renew my arguments, I will openly acknowledge that your
approach does make numerous things easier.  I have little doubt that
it will make merging easier for you personally, as well as addresses
issues with patches that have architecture specific changes (or other
changes that are outside of the current v4l-dvb tree).

So let's talk about why this is bad....

I want to focus my development on v4l-dvb.  That said, I want a stable
codebase on which I can write v4l-dvb drivers, without having to worry
about whether or not my wireless driver is screwed up this week, or
whether the ALSA guys broke my audio support for the fifth time in two
years.  I don't want to wonder whether the crash I just experienced is
because they've replaced the scheduler yet again and they're still
shaking the bugs out.  I don't want to be at the mercy of whatever ABI
changes they're doing this week which break my Nvidia card (and while
I recognize as open source developers we care very little about
"closed source drivers", we shouldn't really find it surprising that
many developers who are rendering HD video might be using Nvidia
cards).

Like most smart developers, I want to have a *controlled* environment
where I can be confident that if a problem arises that it's *my*
changes at fault.  Any time that I spend trying to figure out why my
PC doesn't work is time that I'm not debugging v4l-dvb drivers.

And *THAT* is why it's critical that the mainline not be treated as
"alpha quality" like you suggested last week.  For example, when you
check in alpha code that causes an OOPS whenever any tuner with IR
support is plugged in, I waste several hours debugging the regression
you introduced instead of doing my own work.

Further, we're also changing from a system where we build a relatively
small tree of modules to one where we're going to be
building/installing entire kernels.  Even on my relatively recent
hardware, this is process that takes upwards to an hour (and yes, I do
have ccache).  Even a "make modules_install" can several minutes.  So
now I'm going from being able to "make && make install && make unload"
twenty times an hour to a *MUCH* slower process.

We're giving up the ability to have a fast "debug->compile->test"
cycle for developers in exchange for easier merging of the final
result.  This seems like a poor optimization choice for those of us
who spend all day compiling, debugging, and testing.

Personally, I spend about 98% of my time actively debugging code, and
about 2% of my time dealing with merge issues.  So I *really* care
about things like how long it takes to compile and install the tree.

I hope other developers will offer their opinions on this approach,
since it's all of us who will pay the price in time as a result of
this change.  If all the developers who are writing the code think
it's a good idea to be half as efficient in order to make the merging
easier for one person, then so be it.

The point I'm trying to make is that we need to be having a discussion
about what we are optimizing for, and what are the costs to other
developers.  This is why I'm perhaps a bit pissed to see an
"announcement" declaring how development will be done in the future as
opposed to a discussion of what we could be doing and what are the
trade-offs.

Devin

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

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Hans Verkuil wrote:
> On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote:
>> Hi,

>> Due to that, I'm delegating the task of keeping -hg in sync with upstream and backporting
>> patches to run on older kernels to another person: Douglas has offered his help to keep 
>> the tree synchronized with the -git tree, and to add backport support. 
>>
>> He already started doing that, fixing some incompatibility troubles between some drivers
>> and older kernels.
> 
> Mauro, I just wanted to thank you for doing all the hard work in moving to git!

Anytime!

> I do have one proposal: parts of our hg tree are independent of git: v4l2-apps,
> possibly some firmware build code (not 100% sure of that), v4l_experimental,
> perhaps some documentation stuff. My proposal is that we make a separate hg
> or git tree for those. It will make it easier to package by distros and it makes it
> easier to maintain v4l2-apps et al as well. It might even simplify Douglas's work
> by moving non-essential code out of the compat hg tree.

It may make sense, but I have some comments about it:
	1) v4l_experimental - I think we may just drop it. It was meant to be a staging
area in the old days, but never worked. The 3 drivers there never suffered any maintanership.
Even the firewire driver that used to be there were developed independently. So, IMO, we can
just remove it and, if anyone needs those drivers, they can just look inside the -hg history.

	2) firmware - the code there is just what we have in kernel. While this can be broken,
I can't see much sense, as I don't foresee any changes there: new firmwares are going to
linux-firmware tree and have an upstream maintainership in separate;

	3) media docs - the docs are part of upstream tree. So, it doesn't make sense to have
a separate tree for it. IMO, the proper direction is to merge upstream the capability of 
automatic generation of some xml scripts (like videobuf2.h.xml). Yet, there are a few files
present on v4l2-apps that are also converted to xml, as they are usage examples at the API.
I'm not sure what to do with them.

	4) v4l2-apps - I agree that splitting it could be a good idea, provided that we find
a way to handle the few cases where we have "example" applications at the media docs.
> 
> I'll be updating my daily build scripts to start using git soon (I'll keep using
> hg for the older kernels of course).

That's good! I always check if the -git compiles with x86_64, but I generally don't check
all architectures on my checks.

Cheers,
Mauro.

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Laurent Pinchart wrote:
> Hi Mauro,
> 
> I would like to personally thank you for spending time on git support at 
> linuxtv.org. Git support was a long-awaited feature for many developers (and I 
> certainly was one of them).
> 
> All the work done behind the scene on linuxtv.org isn't seen by end-users and 
> can thus be less rewarding than working on the code. However, it's of critical 
> importance to make the development process as smooth as possible. For that 
> reason, thank you again.

You're welcome!

Working at the infrastructure spends lots of time and, as you said, people
generally only note when there's something broken.

I'm quite confident that supporting -git is the proper path to make life easier
for contributors and developers and opening a new road to the future of the
subsystem.

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories

[Johannes Stezenbach]

On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote:
> 
> BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to 
> mention right now, that one big difference to HG in the way we have used it, is 
> that one developer now can do all the work only with one clone of v4l-dvb and 
> using branches for each development.

Please note that you SHOULD NOT clone from linuxtv.org.
Please follow the description on the top of
http://linuxtv.org/git/

Most linux developers will have a clone of Linus' tree already,
and you can add as many "remotes" to that tree as you like.
It's much faster and more flexible that way.  If you once pulled
a clone of Linus' tree there is simply no need to ever clone
any other Linux tree ever again.

Oh, and if you manage to get your git tree in a state where
you don't know how to fix the mess, don't throw it away.
Go to the git mailing list and ask for advice. They love
customer feeedback. Helps them to improve their product
and make it more user friendly ;-)


Johannes

Re: [ANNOUNCE] git tree repositories

[Patrick Boettcher]

On Tue, 19 Jan 2010, Johannes Stezenbach wrote:

> On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote:
>>
>> BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to
>> mention right now, that one big difference to HG in the way we have used it, is
>> that one developer now can do all the work only with one clone of v4l-dvb and
>> using branches for each development.
>
> Please note that you SHOULD NOT clone from linuxtv.org.
> Please follow the description on the top of
> http://linuxtv.org/git/

Of course I cloned from git.kernel.org and not from linuxtv.org. Still it 
was my first clone of linux ever.

--

Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/

Re: [ANNOUNCE] git tree repositories

[Laurent Pinchart]

Hi Mauro,

On Tuesday 19 January 2010 12:12:58 Mauro Carvalho Chehab wrote:
> Laurent Pinchart wrote:
> > Hi Mauro,
> >
> > I would like to personally thank you for spending time on git support at
> > linuxtv.org. Git support was a long-awaited feature for many developers
> > (and I certainly was one of them).
> >
> > All the work done behind the scene on linuxtv.org isn't seen by end-users
> > and can thus be less rewarding than working on the code. However, it's of
> > critical importance to make the development process as smooth as
> > possible. For that reason, thank you again.
> 
> You're welcome!
> 
> Working at the infrastructure spends lots of time and, as you said, people
> generally only note when there's something broken.
> 
> I'm quite confident that supporting -git is the proper path to make life
> easier for contributors and developers and opening a new road to the
> future of the subsystem.

So am I. I hope the future will prove us right :-)

How do your new git scripts process commits ? In particular, does the 
"Priority:" line still applies ?

-- 
Regards,

Laurent Pinchart

Re: [ANNOUNCE] git tree repositories

[Patrick Boettcher]

Hi Devin,

On Tue, 19 Jan 2010, Devin Heitmueller wrote:
> [..]
>
> I want to focus my development on v4l-dvb.  That said, I want a stable
> codebase on which I can write v4l-dvb drivers, without having to worry
> about whether or not my wireless driver is screwed up this week, or
> whether the ALSA guys broke my audio support for the fifth time in two
> years.  I don't want to wonder whether the crash I just experienced is
> because they've replaced the scheduler yet again and they're still
> shaking the bugs out.  I don't want to be at the mercy of whatever ABI
> changes they're doing this week which break my Nvidia card (and while
> I recognize as open source developers we care very little about
> "closed source drivers", we shouldn't really find it surprising that
> many developers who are rendering HD video might be using Nvidia
> cards).

I agree with Devin. We can't lose and off-tree build system like we have 
it today in v4l-dvb.

What I suggested in my first Email was to put the build system outside the 
v4l-dvb into another repo (e.g. 'v4l-dvb-build') and then telling it to 
make links from the linux-v4l-dvb/ clone.

I'm not sure what needs to be done for the backward-compat with #if
KERNEL_VERSION ... But I'm sure we can find a solution for that.

--

Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Patrick Boettcher wrote:
> On Tuesday 19 January 2010 08:53:10 Hans Verkuil wrote:
>> On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote:
>>> He already started doing that, fixing some incompatibility troubles
>>> between some drivers and older kernels.
>> Mauro, I just wanted to thank you for doing all the hard work in moving to
>>  git!
>>
>> And a big 'thank you' to Douglas as well for taking over hg maintenance!
> 
> A big thank you also from me. 

Wou're welcome.

> I'm strongly in need of a build-only-v4l-dvb build system. Because I'm most of 
> the time using distro-kernels in my productive environments and I'm replacing 
> v4l/dvb drivers with the one from v4l-dvb.

We all need to have some ways to run the new drivers on distro kernels. If not
as a developer, at least as an user. So, I keep believing that the out-of-tree
compilation is fundamental to the success of the subsystem.
> 
> One step into the direction of a solution might be:
> Why not including the v4l-dvb/v4l/Makefile and the related files into that 
> separate repository Hans is describing here and then telling 'make' to make 
> links to ../../v4l-dvb/ instead of ../linux as of today.

This is about what "make kernel-links" do, but in the opposite direction.
It shouldn't be hard do do that, but we need to fix the backports.
In the case of -alsa, they opted to use this strategy for their backported
tree, patching the kernel when building it.

> But I don't know how to solve the ifdef KERNEL_VERSION for having backward 
> compatibility in the source files. Maybe with a patch for each kernel version?

It can be a patch for each kernel version, but this will remove support for some
distro-kernels where the KABI has changed. Another solution is to have a pile
of patches that will be applied as the compilation breaks. This can work, but we
need to find a way to produce those patches.

Maybe the simplest solution is to keep maintaining the -hg and having an auto-generated
tree that will have just the building system and a diff between -git and -hg. If
both are synchronized, the only difference will be the backports.

> BTW: I just made a clone of the git-tree - 365MB *ouff*.

Yes, this is one problem with -git: as it contains the entire kernel struct, and an
history since 2.6.11, it is about 9 times bigger than the -hg tree, where only
the media files are stored.

Yet, git clone has a way to allow removing the history of the kernel, producing a 
small result --depth:

	$ git clone --depth 1 --bare v4l-dvb tmp

This gives about 128M (about 3x -hg). Yet, trees generated with --depth have some
disadvantages.


 Maybe it's worth to 
> mention right now, that one big difference to HG in the way we have used it, is 
> that one developer now can do all the work only with one clone of v4l-dvb and 
> using branches for each development.

Yes. The cost for a new branch is zero. Also, the cost of a new clone is less than
1M, if you use the --shared.

On my daily usage, I use a lot to clone with --shared, and doing my work on independent
directories. The advantage is that you avoid messing your temporary work. You may
even pull or push just one branch into another tree. So, working with git offers
lots of new possibilities to the developers.

Cheers,
Mauro.

> 
> best regards,

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Devin Heitmueller wrote:
> Hello Mauro,
> 
> I find it somewhat unfortunate that this is labeled "ANNOUNCE" instead
> of "RFC".  It shows how little you care about soliciting the opinions
> of the other developers.  Rather than making a proposal for how the
> process can be improved and soliciting feedback, you have chosen to
> decide for all of us what the best approach is and how all of us will
> develop in the future.

The announcement by purpose doesn't contain any changes on the process,
since it requires some discussions before we go there. It is just the
first step, where -git tree support were created. It also announces
that I personally won't keep maintaining -hg, delegating its task
to Douglas.

> The point I'm trying to make is that we need to be having a discussion
> about what we are optimizing for, and what are the costs to other
> developers.  This is why I'm perhaps a bit pissed to see an
> "announcement" declaring how development will be done in the future as
> opposed to a discussion of what we could be doing and what are the
> trade-offs.

I fully understand that supporting the development and tests with an
out of tree building is important to everybody. So, the plans are
to keep the out-of-tree building system maintained, and even
improving it. I'd like to thank to Douglas for his help on making 
this happen.

Cheers,
Mauro.

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

> So am I. I hope the future will prove us right :-)

:)

> How do your new git scripts process commits ? In particular, does the 
> "Priority:" line still applies ?

For patches imported from -hg, the script will handle Priority. For patches
generated against -git, maybe the better is to have separate branches or 
trees: one for fixes and another for new stuff, and an indication, at the
pull request, to what tree the patch will be applied.

We still need some discussions about the process. One of the issues is how
do we'll handle SOB's. My SOB should be added on all patches. Also, sometimes,
patches may need to receive other SOB-like tags, like acked-by. I'm not
sure yet how should we handle it, since a change at the patch description
will change the hash code. -git merge is generally smart enough to not
generate a conflict between two patches with identical diffs, but we need
to do some tests in order to check what would be the better procedure.

Cheers,
Mauro.

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Patrick Boettcher wrote:
> Hi Devin,
> 
> On Tue, 19 Jan 2010, Devin Heitmueller wrote:
>> [..]
>>
>> I want to focus my development on v4l-dvb.  That said, I want a stable
>> codebase on which I can write v4l-dvb drivers, without having to worry
>> about whether or not my wireless driver is screwed up this week, or
>> whether the ALSA guys broke my audio support for the fifth time in two
>> years.  I don't want to wonder whether the crash I just experienced is
>> because they've replaced the scheduler yet again and they're still
>> shaking the bugs out.  I don't want to be at the mercy of whatever ABI
>> changes they're doing this week which break my Nvidia card (and while
>> I recognize as open source developers we care very little about
>> "closed source drivers", we shouldn't really find it surprising that
>> many developers who are rendering HD video might be using Nvidia
>> cards).
> 
> I agree with Devin. We can't lose and off-tree build system like we have
> it today in v4l-dvb.
> 
> What I suggested in my first Email was to put the build system outside
> the v4l-dvb into another repo (e.g. 'v4l-dvb-build') and then telling it
> to make links from the linux-v4l-dvb/ clone.
> 
> I'm not sure what needs to be done for the backward-compat with #if
> KERNEL_VERSION ... But I'm sure we can find a solution for that.

I started a branch with an alternative for if KERNEL_VERSION. Please see:
	http://linuxtv.org/hg/~mchehab/backport/

Basically, it has some perl rules that identifies the points on the source
code where an KABI function has changed and dynamically patches the code.
On my tests, this strategy works fine, but I haven't finished removing
all KERNEL_VERSION checks from the code.

If someone is interested, please be my guest fixing the code and improving it.

Cheers,
Mauro.

> 
> -- 
> 
> Patrick Boettcher - Kernel Labs
> http://www.kernellabs.com/

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Johannes Stezenbach wrote:
> On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote:
>> BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to 
>> mention right now, that one big difference to HG in the way we have used it, is 
>> that one developer now can do all the work only with one clone of v4l-dvb and 
>> using branches for each development.
> 
> Please note that you SHOULD NOT clone from linuxtv.org.
> Please follow the description on the top of
> http://linuxtv.org/git/
> 
> Most linux developers will have a clone of Linus' tree already,
> and you can add as many "remotes" to that tree as you like.

Yes. I have here one "stable" tree that have one "remote" for every stable
tree since 2.6.16.

> It's much faster and more flexible that way.  If you once pulled
> a clone of Linus' tree there is simply no need to ever clone
> any other Linux tree ever again.

Yes. I personally prefer to have a bare clone (bare trees have just
the -git objects, and not a workig tree), and several working copies.
I do the work at the working copies, and, after they are fine, I push
into the bare and send the branches from bare to upstream.

> Oh, and if you manage to get your git tree in a state where
> you don't know how to fix the mess, don't throw it away.
> Go to the git mailing list and ask for advice. They love
> customer feeedback. Helps them to improve their product
> and make it more user friendly ;-)

Yes. One good thing to do is to take a look at "git reflog". It tracks
all the changes you do, and you can always ask git to move to a different
object at the tree, undoing the bad thing you did ;)
> 
> 
> Johannes

Re: [ANNOUNCE] git tree repositories

[Laurent Pinchart]

Hi Mauro,

I've started playing with the linuxtv git repositories. I've cloned v4l-
dvb.git into git://linuxtv.org/pinchartl/uvcvideo.git using git-menu and now 
have trouble pushing changes:

$ git push -v uvcvideo
Pushing to git://linuxtv.org/pinchartl/uvcvideo.git
fatal: The remote end hung up unexpectedly

What URL should I use to push changes ? 

-- 
Regards,

Laurent Pinchart

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Laurent Pinchart wrote:
> Hi Mauro,
> 
> I've started playing with the linuxtv git repositories. I've cloned v4l-
> dvb.git into git://linuxtv.org/pinchartl/uvcvideo.git using git-menu and now 
> have trouble pushing changes:
> 
> $ git push -v uvcvideo
> Pushing to git://linuxtv.org/pinchartl/uvcvideo.git
> fatal: The remote end hung up unexpectedly
> 
> What URL should I use to push changes ? 
> 
Push will only work if you use the ssh url. the url is basically the same
of http, but replacing to ssh:
	ssh://linuxtv.org/git/<tree>

On your case
	ssh://linuxtv.org/git/pinchartl/uvcvideo.git

Cheers,
Mauro.

Re: [ANNOUNCE] git tree repositories

[Laurent Pinchart]

Hi Mauro,

On Tuesday 19 January 2010 14:07:39 Mauro Carvalho Chehab wrote:
> Laurent Pinchart wrote:
> > Hi Mauro,
> >
> > I've started playing with the linuxtv git repositories. I've cloned v4l-
> > dvb.git into git://linuxtv.org/pinchartl/uvcvideo.git using git-menu and
> > now have trouble pushing changes:
> >
> > $ git push -v uvcvideo
> > Pushing to git://linuxtv.org/pinchartl/uvcvideo.git
> > fatal: The remote end hung up unexpectedly
> >
> > What URL should I use to push changes ?
> 
> Push will only work if you use the ssh url. the url is basically the same
> of http, but replacing to ssh:
> 	ssh://linuxtv.org/git/<tree>
> 
> On your case
> 	ssh://linuxtv.org/git/pinchartl/uvcvideo.git

One step further:

$ git push -v uvcvideo
Pushing to ssh://linuxtv.org/git/pinchartl/uvcvideo.git
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

Do I need to upload my public key somewhere ? I already use it with hg push 
(and ssh git-menu) without any issue.

-- 
Cheers,

Laurent Pinchart

Re: [ANNOUNCE] git tree repositories

[Douglas Schilling Landgraf]

Hello Hans,

n 01/19/2010 05:53 AM, Hans Verkuil wrote:
> On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote:
>    
>> Hi,
>>
>> Today, a step to the future was given, in order to help developers to better
>> do their work: the addition of -git support at linuxtv.org server.
>>
>> This is one idea that is being recurrent along the last years: to start using -git
>> as our primary resource for managing the patches at the development[1].
>>
>> At the beginning, the usage CVS for of a SCM (Source Code Management) were
>> choosen on V4L/DVB. Both of the original V4L and DVB trees were developed with the
>> help of cvs. On that time, upstream Linux kernel used to have another tree (BitKeeper).
>>
>> In 2005, both V4L and DVB trees got merged into one cvs repository, and we've
>> discussed about what would be the better SCM solution. We've discussed more
>> about using svn, hg and git. On that time, both hg and git were new technologies,
>> based on the concept of a distributed SCM, where you don't need to go to the
>> server every time you're doing a command at the SCM.
>>
>> Yet, Mercurial were more stable and used, while -git were giving his first
>> steps[2], being used almost only by the Linux Kernel, and several distros didn't use
>> to package it. Git objects were stored uncompressed, generating very large
>> trees. Also, -git tools were complex to use, and some "porcelain" packages were
>> needed, in order to be used by a normal user.
>>
>> So, the decision was made to use mercurial. However, as time goes by, -git got much
>> more eyes than any other SCM, having all their weakness solved, and being developed
>> really fast. Also, it got adopted by several other projects, due to its capability
>> and its number of features.
>>
>> Technically speaking, -git is currently the most advanced distributed open-source
>> SCM application I know.
>>
>> Yet, Mercurial has been doing a very good job maintaining the V4L/DVB trees, and, except
>> for a few points, it does the job.
>>
>> However, the entire Linux Kernel development happens around -git. Even the ones that
>> were adopting other tools (like -alsa, that used to have also Mercurial repositories)
>> migrated to -git.
>>
>> Despite all technical advantages, the rationale for the migration is quite simple:
>> converting patches between different repositories and SCM tools cause development
>> and merge delays, may cause patch mangling and eats lot of the time for people
>> that are part of the process.
>>
>> Also, every time a patch needs to touch on files outside the incomplete tree
>> used at the subsystem, an workaround need to be done, in order to avoid troubles
>> and to be able to send the patch upstream.
>>
>> So, it is simpler to just use -git.
>>
>> Due to all the above reasons, I took some time to add -git support at linuxtv servers.
>> Both http and git methods to retrieve trees were enabled.
>>
>> The new trees will be available at:
>> 	http://linuxtv.org/git/
>>
>> The merge tree, where all submitted patches will be merged, before sending upstream is:
>> 	http://linuxtv.org/git?p=v4l-dvb.git;a=summary
>>
>> This tree is basically a clone of Linus tree, so it runs the latest development kernel.
>> It is also (almost) in sync with our -hg tree (needing just a few adjustments).
>>
>> The above tree will never be rebased, so it should be safe to use it for development.
>>
>> I'll basically merge there all patches I receive. It is OK to submit patches against -hg,
>> since I can still run my old conversion stripts to convert them to -git. However, as
>> the conversion script is not fast (it takes between 15-30 secs to convert a single patch
>> to -git, since it needs to re-generate the entire tree with v4l/scripts/gentree.pl, for
>> ever patch), I kindly ask you to prefer submit me patches directly to -git.
>>
>> With respect to the -hg tree with the out-of-tree building system, We really want to
>> keep having a way to allow running the drivers with kernels other than the latest -rc
>> one, for both development and testing.
>>
>> As you all know, the number of drivers and the average number of merges per day is being
>> increasing, among with more complexity on some drivers that also touches arch and other
>> files outside drivers/media tree. Due to that, lots of my current time is devoted to keep
>> -hg and -git in sync, distracting me from my develoment and maintanership tasks to do it.
>> So, I simply don't have more time to keep maintaining both -hg and -git.
>>
>> Due to that, I'm delegating the task of keeping -hg in sync with upstream and backporting
>> patches to run on older kernels to another person: Douglas has offered his help to keep
>> the tree synchronized with the -git tree, and to add backport support.
>>
>> He already started doing that, fixing some incompatibility troubles between some drivers
>> and older kernels.
>>      
> Mauro, I just wanted to thank you for doing all the hard work in moving to git!
>
> And a big 'thank you' to Douglas as well for taking over hg maintenance!
>    

You are welcome!

> I do have one proposal: parts of our hg tree are independent of git: v4l2-apps,
> possibly some firmware build code (not 100% sure of that), v4l_experimental,
> perhaps some documentation stuff. My proposal is that we make a separate hg
> or git tree for those. It will make it easier to package by distros and it makes it
> easier to maintain v4l2-apps et al as well. It might even simplify Douglas's work
> by moving non-essential code out of the compat hg tree.
>
> I'll be updating my daily build scripts to start using git soon (I'll keep using
> hg for the older kernels of course).
>
>    

Thanks for doing the daily build email, helps a lot. Also, helps bring 
more people involved with the
subsystem.

Cheers,
Douglas

Re: [ANNOUNCE] git tree repositories

[Bob Cunningham]

On 01/19/2010 04:16 AM, Mauro Carvalho Chehab wrote:
> Devin Heitmueller wrote:
>> Hello Mauro,
>>
>> I find it somewhat unfortunate that this is labeled "ANNOUNCE" instead
>> of "RFC".  It shows how little you care about soliciting the opinions
>> of the other developers.  Rather than making a proposal for how the
>> process can be improved and soliciting feedback, you have chosen to
>> decide for all of us what the best approach is and how all of us will
>> develop in the future.
>
> The announcement by purpose doesn't contain any changes on the process,
> since it requires some discussions before we go there. It is just the
> first step, where -git tree support were created. It also announces
> that I personally won't keep maintaining -hg, delegating its task
> to Douglas.
>
>> The point I'm trying to make is that we need to be having a discussion
>> about what we are optimizing for, and what are the costs to other
>> developers.  This is why I'm perhaps a bit pissed to see an
>> "announcement" declaring how development will be done in the future as
>> opposed to a discussion of what we could be doing and what are the
>> trade-offs.
>
> I fully understand that supporting the development and tests with an
> out of tree building is important to everybody. So, the plans are
> to keep the out-of-tree building system maintained, and even
> improving it. I'd like to thank to Douglas for his help on making
> this happen.
>
> Cheers,
> Mauro.

I'm primarily a lurker on this list, generally content to wait for v4l driver updates until they appear in the Fedora 12 and Ubuntu 9.10 updates.

However, I also keep a v4l source tree around that I update and build whenever any significant changes occur that affect my HVR-950Q, so I can provide rapid feedback to the developers.  My process is to update my local tree, build the drivers. build the package, install the package, test it, then either revert immediately if there are problems (after posting to the list), or update again when the changes appear in the Fedora repositories.

Am I correct to believe my process will not be affected by the shift to git?  That is, will existing kernels will still have access to the current v4l code via hg?

I also hope to one day start working on an unsupported USB tuner I have laying around (should be simple, but after nearly a year I still haven't gotten to it).  Will I be permitted to do my development, and contribute changes, using hg and the current Fedora kernel?

Lurker testers and wannabe developers need to know!

-BobC

Re: [ANNOUNCE] git tree repositories

[Johannes Stezenbach]

Hi,

may I humbly request to make it mandatory to enter a description
when a user creates a new tree on linuxtv.org?
IMHO "foobar development repository" isn't useful at all.

If I look at http://linuxtv.org/hg/ many times I have no
clue what a repo is about or why it exists at all.
Let's not repeat the same mistake with git.

OTOH, since with git it is common to have multiple branches
within one repository, I'm not sure how it works. It would
be cool if git would support per-branch descriptions,
and git web could display them.


Johannes

Re: [ANNOUNCE] git tree repositories

[hermann pitton]

Hi Bob,

Am Dienstag, den 19.01.2010, 13:21 -0800 schrieb Bob Cunningham:
> On 01/19/2010 04:16 AM, Mauro Carvalho Chehab wrote:
> > Devin Heitmueller wrote:
> >> Hello Mauro,
> >>
> >> I find it somewhat unfortunate that this is labeled "ANNOUNCE" instead
> >> of "RFC".  It shows how little you care about soliciting the opinions
> >> of the other developers.  Rather than making a proposal for how the
> >> process can be improved and soliciting feedback, you have chosen to
> >> decide for all of us what the best approach is and how all of us will
> >> develop in the future.
> >
> > The announcement by purpose doesn't contain any changes on the process,
> > since it requires some discussions before we go there. It is just the
> > first step, where -git tree support were created. It also announces
> > that I personally won't keep maintaining -hg, delegating its task
> > to Douglas.
> >
> >> The point I'm trying to make is that we need to be having a discussion
> >> about what we are optimizing for, and what are the costs to other
> >> developers.  This is why I'm perhaps a bit pissed to see an
> >> "announcement" declaring how development will be done in the future as
> >> opposed to a discussion of what we could be doing and what are the
> >> trade-offs.
> >
> > I fully understand that supporting the development and tests with an
> > out of tree building is important to everybody. So, the plans are
> > to keep the out-of-tree building system maintained, and even
> > improving it. I'd like to thank to Douglas for his help on making
> > this happen.
> >
> > Cheers,
> > Mauro.
> 
> I'm primarily a lurker on this list, generally content to wait for v4l driver updates until they appear in the Fedora 12 and Ubuntu 9.10 updates.
> 
> However, I also keep a v4l source tree around that I update and build whenever any significant changes occur that affect my HVR-950Q, so I can provide rapid feedback to the developers.  My process is to update my local tree, build the drivers. build the package, install the package, test it, then either revert immediately if there are problems (after posting to the list), or update again when the changes appear in the Fedora repositories.
> 
> Am I correct to believe my process will not be affected by the shift to git?  That is, will existing kernels will still have access to the current v4l code via hg?
> 
> I also hope to one day start working on an unsupported USB tuner I have laying around (should be simple, but after nearly a year I still haven't gotten to it).  Will I be permitted to do my development, and contribute changes, using hg and the current Fedora kernel?
> 
> Lurker testers and wannabe developers need to know!
> 
> -BobC

if you look at the history of v4l, you can be sure that we always tried
to have as much testers as possible.

During the 2.5.x development cycle, in fact all testing and development
was done on 2.4.x. We did not even have any SCM that time, but on 2.5.x
problems Devin is pointing to were enormous.

Mike Krufky and Mauro were always strong in defending backward compat,
also after taking over Gerd's cvs he later had.

Mauro, in the beginning, even always tried to keep usability back to
2.4.x kernels with v4l2 revision 1 and I did warn him, that this task is
quite impossible to satisfy, but we had developers on totally outdated
semi proprietary stuff, years in delay, asking exactly for that.

On latest discussions, how far we should keep backward compat after i2c
improvements, you saw Mauro again voting for as far as ever possible.

Be sure, we don't want to lose you guys!

Cheers,
Hermann

Re: [ANNOUNCE] git tree repositories

[Andy Walls]

On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:

> BTW: I just made a clone of the git-tree - 365MB *ouff*.

Assuming 53.333 kbps download speed, 0% overhead, no compression:

365 MiB * 2^20 bytes/MiB * 8 bits/byte / 53333 bits/sec / 3600 sec/hr =
15.95 hours

:(

Can git resume aborted clones?  It could be many weeks before I have a
20 hour window where I don't have to use my land line phone for voice...

Regards,
Andy

Re: [ANNOUNCE] git tree repositories

[hermann pitton]

Am Dienstag, den 19.01.2010, 18:38 -0500 schrieb Andy Walls: 
> On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
> 
> > BTW: I just made a clone of the git-tree - 365MB *ouff*.
> 
> Assuming 53.333 kbps download speed, 0% overhead, no compression:
> 
> 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 53333 bits/sec / 3600 sec/hr =
> 15.95 hours
> 
> :(
> 
> Can git resume aborted clones?  It could be many weeks before I have a
> 20 hour window where I don't have to use my land line phone for voice...
> 
> Regards,
> Andy
> 


Hi Andy,

:) please take it only as that.

What about assuming a 1800 kbps low level flat rate and all phone calls
for free, except for some "exotic" ;) mobile net providers, for the
whole family, including a mobile flat, 4 different phone numbers, video
on demand, and much more you don't need, for 30€ per months?

It is always said, we are so much in delay with such here, but seeing
the above calculation, it is ten years back paying for nothing the
triple money and wait for a day. And preferably the phone of course is
blocked during that.

You are living in the USA? Seems sending CDs per express air mail is
much cheaper ..., even using Brazil as a relay ;)

Are you sure, you did not miss to update your provider ten years back
the first time?

We have local traffic since years, leaving Germany in the north, coming
in over there through Canada, crossing the whole States, and coming back
from Florida to arrive a few miles away from me, just because of unused
backbones. Also VOIP calls are quite fine these days, but local
thunderstorms in between are still often a disaster for hours in summer.

Taking the smileys out now, in fact distributions have Gigas of updates
within a few weeks these days. Andy for sure has an argument.


Cheers,
Hermann

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Andy Walls wrote:
> On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
> 
>> BTW: I just made a clone of the git-tree - 365MB *ouff*.
> 
> Assuming 53.333 kbps download speed, 0% overhead, no compression:
> 
> 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 53333 bits/sec / 3600 sec/hr =
> 15.95 hours

It is an one time download, since, once you got it, the updates are cheap.

Btw, it is a way small than a single CD needed for you to install Linux.

If you want to get it and you're not willing to pay to a decent Internet
connection, just ask someone to get it for you and save on a CD.

Of course you can also keep using -hg.

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories

[Andy Walls]

On Wed, 2010-01-20 at 02:10 +0100, hermann pitton wrote:
> Am Dienstag, den 19.01.2010, 18:38 -0500 schrieb Andy Walls: 
> > On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
> > 
> > > BTW: I just made a clone of the git-tree - 365MB *ouff*.
> > 
> > Assuming 53.333 kbps download speed, 0% overhead, no compression:
> > 
> > 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 53333 bits/sec / 3600 sec/hr =
> > 15.95 hours
> > 
> > :(
> > 
> > Can git resume aborted clones?  It could be many weeks before I have a
> > 20 hour window where I don't have to use my land line phone for voice...
> > 
> > Regards,
> > Andy
> > 
> 
> 
> Hi Andy,
> 
> :) please take it only as that.


:)

> What about assuming a 1800 kbps low level flat rate and all phone calls
> for free, except for some "exotic" ;) mobile net providers, for the
> whole family, including a mobile flat, 4 different phone numbers, video
> on demand, and much more you don't need, for 30€ per months?
> 
> It is always said, we are so much in delay with such here, but seeing
> the above calculation, it is ten years back paying for nothing the
> triple money and wait for a day. And preferably the phone of course is
> blocked during that.

Yes, I realize I am in the dark ages.

I haven't been able to build a cost case for my normal home
communications needs to pay for Cable or Satellite internet service.  I
really dislike monthly recurring household costs for services that bill
me whether I use them or not, like communications.  I try to pay only
for plans that meet my common usage needs and no more.

My oldest child is to the point where she will need to start using the
internet for research for school next year.  I'll have to open my wallet
soon, as my household communications needs are growing.


> You are living in the USA? Seems sending CDs per express air mail is
> much cheaper ..., even using Brazil as a relay ;)

You beat me to that joke.  Although I was going to say New Zealand...


> Are you sure, you did not miss to update your provider ten years back
> the first time?

I live in a very rural area:  No fiber optic, no DSL, EV-DO requires
directional antenna and amplifier.

Cable TV & internet is available, but is unreliable and expensive.
Satellite internet is available, of course.


Regards,
Andy

> Taking the smileys out now, in fact distributions have Gigas of updates
> within a few weeks these days. Andy for sure has an argument.
> 
> 
> Cheers,
> Hermann

Re: [ANNOUNCE] git tree repositories

[Andy Walls]

On Wed, 2010-01-20 at 01:29 -0200, Mauro Carvalho Chehab wrote: 
> Andy Walls wrote:
> > On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
> > 
> >> BTW: I just made a clone of the git-tree - 365MB *ouff*.
> > 
> > Assuming 53.333 kbps download speed, 0% overhead, no compression:
> > 
> > 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 53333 bits/sec / 3600 sec/hr =
> > 15.95 hours
> 
> It is an one time download, since, once you got it, the updates are cheap.
> 
> Btw, it is a way small than a single CD needed for you to install Linux.
> 
> If you want to get it and you're not willing to pay to a decent Internet
> connection,

If only I could pay for a *decent* one.

If I just want bandwidth at a poor level of service, poor reliability
and high cost, then I'll pay for the local cable TV internet service.

I'm in one of the white areas on the map on page 33 of:

http://www.tccsmd.org/downloads/Broadband%20Final%20Report.pdf

I don't really have options for getting a good value for my dollar on
broadband internet.

(The residential broadband deployment in the US is just terrible IMO.)


> just ask someone to get it for you and save on a CD.

Nah.  Next time I head to the library, I'll just bring a laptop along:
free WiFi.


> Of course you can also keep using -hg.

That was my plan.

Regards,
Andy

> Cheers,
> Mauro

Re: [ANNOUNCE] git tree repositories

[Markus Heidelberg]

Mauro Carvalho Chehab, 2010-01-19:
> Yes. I personally prefer to have a bare clone (bare trees have just
> the -git objects, and not a workig tree), and several working copies.
> I do the work at the working copies, and, after they are fine, I push
> into the bare and send the branches from bare to upstream.

Do you know git-new-workdir? It's included in the contrib area of the
git installation.
Instead of cloning your own local repository to get a new working
directory, with this script you really only get a new working directory
and can work in it as if it was the original clone. Then you don't have
to deal with pushes between local repositories.

Markus

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede]

Hi,

On 01/19/2010 12:08 PM, Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
>> On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote:

<snip>

>> I do have one proposal: parts of our hg tree are independent of git: v4l2-apps,
>> possibly some firmware build code (not 100% sure of that), v4l_experimental,
>> perhaps some documentation stuff. My proposal is that we make a separate hg
>> or git tree for those. It will make it easier to package by distros and it makes it
>> easier to maintain v4l2-apps et al as well. It might even simplify Douglas's work
>> by moving non-essential code out of the compat hg tree.
>
> It may make sense, but I have some comments about it:

<snip>

> 	4) v4l2-apps - I agree that splitting it could be a good idea, provided that we find
> a way to handle the few cases where we have "example" applications at the media docs.
>>

Note that v4l2-apps also contains libv4l, it so happens that I've been discussing moving
libv4l to its own git tree with Brandon Philips. Preferably to a place which also offers
some form of bug tracking. The advantages of having libv4l in its own tree are:

-it is maintained independent of the hg tree anyways
-it has regular versioned tarbal releases, it would be good to be able to tag these
  inside the used scm, which is hard to do when the scm is shared with other unrelated
  code which does not end up in said tarballs
-this means having a much smaller tree making it easier to clone
-no longer having an often old (stale) libv4l in the master hg repository
  (this is partially my fault as I should send pull requests for libv4l moe often,
   but why all this synchronization overhead when its independent anyways)

As said when discussing this with Brandon we were thinking about using something
like github, as that offers bug tracking too. But I can understand if you would prefer
to keep libv4l at linuxtv.org .

The last few fays I've been working on making a stand alone version of the uvcdynctrl
tool, which is meant to send a userspace database of vendor specific controls to
the uvcvideo driver, after which they will show up as regular v4l2 controls.

The uvcdynctrl utility is part of the libwebcam project:
http://www.quickcamteam.net/software/libwebcam

But given that libwebcam is unmaintained and not used by anything AFAIK, I'm patching
uvcdynctrl to no longer need it. The plan is to add uvcdynctrl to libv4l soon, as that
is needed to be able to control the focus on some uvc autofocus cameras.

This means that libv4l will be growing a set of utilities, currently just uvcdynctrl
(and its database and udev scripts), but given this precedent we could add more
utilities to libv4l. I wouldn't mind moving v4l2-ctl and v4l2-dbg to libv4l, this would
also have the advantage that since most distro's ship libv4l these utilities would
actually become available to end users (which AFAIK currently they are not in most
distros).

Regards,

Hans

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans Verkuil]

Hi Hans,

> Hi,
>
> On 01/19/2010 12:08 PM, Mauro Carvalho Chehab wrote:
>> Hans Verkuil wrote:
>>> On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote:
>
> <snip>
>
>>> I do have one proposal: parts of our hg tree are independent of git:
>>> v4l2-apps,
>>> possibly some firmware build code (not 100% sure of that),
>>> v4l_experimental,
>>> perhaps some documentation stuff. My proposal is that we make a
>>> separate hg
>>> or git tree for those. It will make it easier to package by distros and
>>> it makes it
>>> easier to maintain v4l2-apps et al as well. It might even simplify
>>> Douglas's work
>>> by moving non-essential code out of the compat hg tree.
>>
>> It may make sense, but I have some comments about it:
>
> <snip>
>
>> 	4) v4l2-apps - I agree that splitting it could be a good idea, provided
>> that we find
>> a way to handle the few cases where we have "example" applications at
>> the media docs.
>>>
>
> Note that v4l2-apps also contains libv4l, it so happens that I've been
> discussing moving
> libv4l to its own git tree with Brandon Philips. Preferably to a place
> which also offers
> some form of bug tracking. The advantages of having libv4l in its own tree
> are:
>
> -it is maintained independent of the hg tree anyways
> -it has regular versioned tarbal releases, it would be good to be able to
> tag these
>   inside the used scm, which is hard to do when the scm is shared with
> other unrelated
>   code which does not end up in said tarballs
> -this means having a much smaller tree making it easier to clone
> -no longer having an often old (stale) libv4l in the master hg repository
>   (this is partially my fault as I should send pull requests for libv4l
> moe often,
>    but why all this synchronization overhead when its independent anyways)
>
> As said when discussing this with Brandon we were thinking about using
> something
> like github, as that offers bug tracking too. But I can understand if you
> would prefer
> to keep libv4l at linuxtv.org .
>
> The last few fays I've been working on making a stand alone version of the
> uvcdynctrl
> tool, which is meant to send a userspace database of vendor specific
> controls to
> the uvcvideo driver, after which they will show up as regular v4l2
> controls.
>
> The uvcdynctrl utility is part of the libwebcam project:
> http://www.quickcamteam.net/software/libwebcam
>
> But given that libwebcam is unmaintained and not used by anything AFAIK,
> I'm patching
> uvcdynctrl to no longer need it. The plan is to add uvcdynctrl to libv4l
> soon, as that
> is needed to be able to control the focus on some uvc autofocus cameras.
>
> This means that libv4l will be growing a set of utilities, currently just
> uvcdynctrl
> (and its database and udev scripts), but given this precedent we could add
> more
> utilities to libv4l. I wouldn't mind moving v4l2-ctl and v4l2-dbg to
> libv4l, this would
> also have the advantage that since most distro's ship libv4l these
> utilities would
> actually become available to end users (which AFAIK currently they are not
> in most
> distros).

It seems to me that creating a v4l2-apps tree (similar to dvb-apps) would
solve most of these issues (except for bug tracking). We would need to do
some rearranging in the directory structure of v4l2-apps, though. It is a
bit of a mix of production code like libv4l and v4l2-ctl, v4l2-dbg.
cx18-ctl and ivtv-ctl, and more test or debug oriented tools. The latter
do not need to be packaged by distros.

Personally I would prefer to keep v4l2-apps on linuxtv.org. But the strict
commit procedure that we have for the main v4l-dvb repo can be relaxed
here. So it should be possible for you to have commit rights so you can
use it as your master repository.

Mauro, what do you think?

Regards,

        Hans

>
> Regards,
>
> Hans
>


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

Re: [ANNOUNCE] git tree repositories & libv4l

[Laurent Pinchart]

Hi Hans,

On Wednesday 20 January 2010 09:36:08 Hans de Goede wrote:
> Hi,
> 
> On 01/19/2010 12:08 PM, Mauro Carvalho Chehab wrote:
> > Hans Verkuil wrote:
> >> On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote:
> 
> <snip>
> 
> >> I do have one proposal: parts of our hg tree are independent of git:
> >> v4l2-apps, possibly some firmware build code (not 100% sure of that),
> >> v4l_experimental, perhaps some documentation stuff. My proposal is that
> >> we make a separate hg or git tree for those. It will make it easier to
> >> package by distros and it makes it easier to maintain v4l2-apps et al as
> >> well. It might even simplify Douglas's work by moving non-essential code
> >> out of the compat hg tree.
> >
> > It may make sense, but I have some comments about it:
> 
> <snip>
> 
> > 	4) v4l2-apps - I agree that splitting it could be a good idea, provided
> > that we find a way to handle the few cases where we have "example"
> > applications at the media docs.
> 
> Note that v4l2-apps also contains libv4l, it so happens that I've been
>  discussing moving libv4l to its own git tree with Brandon Philips.
>  Preferably to a place which also offers some form of bug tracking. The
>  advantages of having libv4l in its own tree are:
> 
> -it is maintained independent of the hg tree anyways
> -it has regular versioned tarbal releases, it would be good to be able to
>  tag these inside the used scm, which is hard to do when the scm is shared
>  with other unrelated code which does not end up in said tarballs
> -this means having a much smaller tree making it easier to clone
> -no longer having an often old (stale) libv4l in the master hg repository
>   (this is partially my fault as I should send pull requests for libv4l moe
>  often, but why all this synchronization overhead when its independent
>  anyways)
> 
> As said when discussing this with Brandon we were thinking about using
>  something like github, as that offers bug tracking too. But I can
>  understand if you would prefer to keep libv4l at linuxtv.org .
> 
> The last few fays I've been working on making a stand alone version of the
>  uvcdynctrl tool, which is meant to send a userspace database of vendor
>  specific controls to the uvcvideo driver, after which they will show up as
>  regular v4l2 controls.

Thanks for that, it's much appreciated. If you have any concern with the 
uvcvideo driver userspace API I'd be happy to discuss them.

> The uvcdynctrl utility is part of the libwebcam project:
> http://www.quickcamteam.net/software/libwebcam
> 
> But given that libwebcam is unmaintained and not used by anything AFAIK,
>  I'm patching uvcdynctrl to no longer need it. The plan is to add
>  uvcdynctrl to libv4l soon, as that is needed to be able to control the
>  focus on some uvc autofocus cameras.
> 
> This means that libv4l will be growing a set of utilities, currently just
>  uvcdynctrl (and its database and udev scripts), but given this precedent
>  we could add more utilities to libv4l. I wouldn't mind moving v4l2-ctl and
>  v4l2-dbg to libv4l, this would also have the advantage that since most
>  distro's ship libv4l these utilities would actually become available to
>  end users (which AFAIK currently they are not in most distros).

-- 
Cheers,

Laurent Pinchart

Re: [ANNOUNCE] git tree repositories & libv4l

[Paulo Assis]

Hi,

> The uvcdynctrl utility is part of the libwebcam project:
> http://www.quickcamteam.net/software/libwebcam
>
> But given that libwebcam is unmaintained and not used by anything AFAIK, I'm
> patching
> uvcdynctrl to no longer need it. The plan is to add uvcdynctrl to libv4l
> soon, as that
> is needed to be able to control the focus on some uvc autofocus cameras.

Actually libwebcam is still maintained in svn:

http://www.quickcamteam.net/documentation/how-to/how-to-install-the-webcam-tools

but you are right just a few applications use it, and since it's not
yet included in any distribution most end users will miss some advance
features on their webcams.
I'm just a bit worried that having two different packages providing
the same set of tools may cause some compatibility problems in the
future. Binary packages of libwebcam are being prepared and will be
available soon, so I guess some compat tests may be in order, maybe
splitting uvcdynctrl from libwebcam into a different package and
making it incompatible with libv4l would be a good idea.

Regards,
Paulo

Re: [ANNOUNCE] git tree repositories

[BOUWSMA Barry]

Moin Andy,

On Tue, 19 Jan 2010, Andy Walls wrote:

> On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
> 
> > BTW: I just made a clone of the git-tree - 365MB *ouff*.
> 
> Assuming 53.333 kbps download speed, 0% overhead, no compression:
> 
> 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 53333 bits/sec / 3600 sec/hr =
> 15.95 hours
> 
> :(

Wow, that's about twice as fast as my first clone of the 
various SCM trees, mostly with CVSup, many years ago, after
leaving the world of high-speedLand.  Actually, when I made
my first git kernel clone, I think it was less than 100MB
yet still elicited the same astoundment I see now.

And basically I did dial in and let all the checkouts run
overnight from whichever provider was affordable, back when
the per-minute costs were ten to 100 times what I see today.

Although many other BSD full trees were updates of changes
that had then occurred in five years, and CVSup/rsync and
the like can do the work in bits and pieces.



> Can git resume aborted clones?  It could be many weeks before I have a
> 20 hour window where I don't have to use my land line phone for voice...

Unfortunately, my experience has been no, both in initial
checkouts, and in large updates -- if I go for a month without
pulling Linus' latest changes, with the poor connectivity I
have, sometimes it will take three or four attempts until I
can get all those handful of megabytes of chunks intact at
once.

Worse is if your ISP has you on a configuration that doesn't
preserve your IP for the duration of your download, changing
it every few minutes, or hours, as is a common practice to
keep customers from running servers or doing anything useful.
The net was made for surfing, not downloading, dammit.


I am writing from the point of view of a beginner who knows
nothing about the advantages of `git' or `hg' or `svn' and
friends and who only wants to clone the entire development
tree locally for off-line work with access to any point of
development, and as such I don't know of any possible expert
flags like ``--partial'' or something to instruct `git' not
to discard any complete or partial chunks.  In fact, I don't 
remember if I downloaded the original kernel in any special way, 
such as a .tbz file to be used as a base and then updated from 
there.  So don't take my word as gospel.


barry bouwsma
in the middle of an aborted-after-four-hours update of FreeBSD 
during the bandwidth-hungry ``fixup'' process that thanks to 
their accursed move to `svn' seems to take much longer than just
pulling the deltas alone, but luckily which I can resume once I
get ``better'' connectivity and not lose much of anything.
grumble mumble old fart grumble

libwecam & uvcdynctrl (was Re: [ANNOUNCE] git tree repositories & libv4l)

[Hans de Goede]

Hi,

On 01/20/2010 10:54 AM, Paulo Assis wrote:
> Hi,
>
>> The uvcdynctrl utility is part of the libwebcam project:
>> http://www.quickcamteam.net/software/libwebcam
>>
>> But given that libwebcam is unmaintained and not used by anything AFAIK, I'm
>> patching
>> uvcdynctrl to no longer need it. The plan is to add uvcdynctrl to libv4l
>> soon, as that
>> is needed to be able to control the focus on some uvc autofocus cameras.
>
> Actually libwebcam is still maintained in svn:
>

Looking at the clog, maintained is a very big word here, there is some activity
here but very little to speak of.

> http://www.quickcamteam.net/documentation/how-to/how-to-install-the-webcam-tools
>

Looking at that page, the only reason stated there to install it is
uvcdynctrl, not libwebcam itself. And the installation as described there
is a pain.

Also the current state of uvcdynctrl + uvcvideo + the xml database is not
exactly one that is end user ready.

The reset pan/tilt controls don't work properly (they should be of the
button type).

The led controls don't work properly (the led control one should be
a menu, the frequency should have a minimum of 1 not 0).

I'm working on:

1) Dropping the unnecessary libwebcam dependency (done), which was
    surprisingly easy. There really is nothing uvcdynctrl needs libwebcam
    for, other then uvcvideo /dev/video devices detection, but given
    that uvcdynctrl's primary use will be from udev, there is no need
    for that, the udev rule can simply pass in the device node as argument.

2) Making installation a breeze (and getting it included in most distros)

3) Making it actually user friendly, once uvcdynctrl is executed a user should
be able to startup a gui v4l2 control panel like v4l2ucp and have meaning full,
working controls there, without any error messages being shown.

> but you are right just a few applications use it, and since it's not
> yet included in any distribution most end users will miss some advance
> features on their webcams.
> I'm just a bit worried that having two different packages providing
> the same set of tools may cause some compatibility problems in the
> future. Binary packages of libwebcam are being prepared and will be
> available soon, so I guess some compat tests may be in order, maybe
> splitting uvcdynctrl from libwebcam into a different package and
> making it incompatible with libv4l would be a good idea.
>

My plan is to remove the dependency of uvcdynctrl on libwebcam, and
then incorporate uvcdynctrl inside libv4l. I was doing this under
the assumption that the libwebcam project was pretty much dead, I was
already planning on mailing Martin Rubli and will do so shortly.

I have various requests from users who need the additional controls
(for things like focus on the "Logitech Quickcam Pro 9000"), and was
asked to incorporate uvcdynctrl into libv4l by Laurens Pinchart.

I'm sorry if this comes over as hijacking the code / project, that is
not what this is about, this is about enabling the additional controls
for end users in a plug and play way. Which I believe is easiest done
by adding uvcdynctrl to libv4l, as that is actively maintained and
packaged in most distros.

Regards,

Hans

Re: [ANNOUNCE] git tree repositories

[BOUWSMA Barry]

On Wed, 20 Jan 2010, Mauro Carvalho Chehab wrote:

> Andy Walls wrote:
> > On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
> > 
> >> BTW: I just made a clone of the git-tree - 365MB *ouff*.
> > 
> > Assuming 53.333 kbps download speed, 0% overhead, no compression:
> > 
> > 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 53333 bits/sec / 3600 sec/hr =
> > 15.95 hours
> 
> It is an one time download, since, once you got it, the updates are cheap.

Getting a bit off-topic here, but hey....

Yes, but it is that first step of getting the download that is
the problem.

Until the tree ends up with a conflicted merge (has happened to
me a few times), and then a beginner such as myself has no idea
what to do and pushes the tree out of the way and starts anew
(or decides to give up on the tree that's no longer so much of
interest), but that's when I've had better connectivity than
Sir Walls here.


A big problem I see and which will affect the majority of people
on less-than-ideal connections is that the initial clone is that
the `git clone' for such a large tree is not something you can
pick up if interrupted in the middle.  I'd hate to be in Andy's
house as he's drenched with sweat clenching the arms of his
chair watching the progress bar go from 98% to 99% to
^%{3f{NO CARRIER as someone on his party line down the road
picks up the phone to chat with their sister in the next room.
Actually, that's not true, I'd love to hear it as I'm sure there
are a good variety of swear words I haven't learned from the time
I had me mouth washed out with Irish Spring, carried on to this
day by gargling every evening with Fairy Liquid.



> Btw, it is a way small than a single CD needed for you to install Linux.

But `wget' has an option to resume the download, even if it takes
a week to get the entire CD as it did me.  Or better, as I used,
`jigdo' which splits the download even further, automagically
uses `wget' in shortened `retry' mode, and allows me to get the
missing parts elsewhere -- before, like `git' or other SCM
frontends, getting incremental updates.

That is what seems to be missing from `git', in spite of its
other advantages over `rsync' or `CVSup', for an initial download.


> If you want to get it and you're not willing to pay to a decent Internet
> connection, just ask someone to get it for you and save on a CD.

This is not a good attitude to have -- I have been in places with
no practical internet connection and places where it was not worth
it to pay for a ``decent'' connection.  Still, I tried to get on-
line when possible.

You are also working with volunteers who are putting out their own
money to get connectivity.  I'm sure that I am not the only one on
the list who is unable to get a satisfactory decent-paying job at
present, but who is willing to donate time and some resources to
advance Linux and other free software.  To do so I rely on more
fortunate friends who can afford a decent connection, when most of
my usage wouldn't even be noticed on a dial-up connection.


Sorry, I'm just ranting.  Ignore me.  Or I'll blow you all 
sky-high after a week.

barry bouwsma
no-fly zone, until spring

Re: [ANNOUNCE] git tree repositories

[Laurent Pinchart]

Hi Devin,

I think Mauro made it quite clear that this was just an announcement for work 
in progress that has been started on git support and that we still need to 
discuss how we will handle backports/compatibility with older kernels, so I'll 
go straight to the point I want to make.

On Tuesday 19 January 2010 11:04:13 Devin Heitmueller wrote:

[snip]

> I want to focus my development on v4l-dvb.  That said, I want a stable
> codebase on which I can write v4l-dvb drivers, without having to worry
> about whether or not my wireless driver is screwed up this week, or
> whether the ALSA guys broke my audio support for the fifth time in two
> years.  I don't want to wonder whether the crash I just experienced is
> because they've replaced the scheduler yet again and they're still
> shaking the bugs out.  I don't want to be at the mercy of whatever ABI
> changes they're doing this week which break my Nvidia card (and while
> I recognize as open source developers we care very little about
> "closed source drivers", we shouldn't really find it surprising that
> many developers who are rendering HD video might be using Nvidia
> cards).

I totally agree with you here. We obviously don't support developers who still 
want to use a 2.4.x kernel on their computer, so a line as to be drawn at some 
point.

This being said, I think we should not base the v4l-dvb git tree on the very 
latest Linus' tree. Linus himself stated during the LPC 2009 that subsystems 
should not pull from his tree at random point, but should rather use main 
kernel versions, or at least -rc versions. I think that basing the v4l-dvb 
tree on top of the last tag from mainline would be a better practice than 
pulling from it everyday.

This will obviously not solve the issue you mention, which is why we still 
need to agree on a nice way to handle backports, but that will make life 
easier for developers who want to try the v4l-dvb subsystem on top of the most 
recent kernel.

-- 
Regards,

Laurent Pinchart

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Laurent Pinchart wrote:
> Hi Devin,

> I totally agree with you here. We obviously don't support developers who still 
> want to use a 2.4.x kernel on their computer, so a line as to be drawn at some 
> point.

Currently, the backport starts on 2.6.16. I think it is ok to keep this as the
basis version.

> This being said, I think we should not base the v4l-dvb git tree on the very 
> latest Linus' tree. Linus himself stated during the LPC 2009 that subsystems 
> should not pull from his tree at random point, but should rather use main 
> kernel versions, or at least -rc versions. I think that basing the v4l-dvb 
> tree on top of the last tag from mainline would be a better practice than 
> pulling from it everyday.

A good compromise here would be to use the latest main kernel version for fix
patches that needs to go also to -stable and -rc1 for the other fixes and 
development patches.

> This will obviously not solve the issue you mention, which is why we still 
> need to agree on a nice way to handle backports, but that will make life 
> easier for developers who want to try the v4l-dvb subsystem on top of the most 
> recent kernel.

Agreed.

Cheers,
Mauro.

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Andy Walls wrote:
> On Wed, 2010-01-20 at 01:29 -0200, Mauro Carvalho Chehab wrote: 
>> Andy Walls wrote:
>>> On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote:
>>>
>>>> BTW: I just made a clone of the git-tree - 365MB *ouff*.
>>> Assuming 53.333 kbps download speed, 0% overhead, no compression:
>>>
>>> 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 53333 bits/sec / 3600 sec/hr =
>>> 15.95 hours
>> It is an one time download, since, once you got it, the updates are cheap.
>>
>> Btw, it is a way small than a single CD needed for you to install Linux.
>>
>> If you want to get it and you're not willing to pay to a decent Internet
>> connection,
> 
> If only I could pay for a *decent* one.
> 
> If I just want bandwidth at a poor level of service, poor reliability
> and high cost, then I'll pay for the local cable TV internet service.
> 
> I'm in one of the white areas on the map on page 33 of:
> 
> http://www.tccsmd.org/downloads/Broadband%20Final%20Report.pdf
> 
> I don't really have options for getting a good value for my dollar on
> broadband internet.
> 
> (The residential broadband deployment in the US is just terrible IMO.)

Rural areas are more problematic. Here, in Brazil, we have a good coverage at
low and fixed cost via cellular (about US$40,00/mo for 1Mb bandwidth). Yet, on
rural areas, there's no 3G support, so it drops to EDGE or 2G speed. I have
one of this, plus a xDSL link.

>> just ask someone to get it for you and save on a CD.
> 
> Nah.  Next time I head to the library, I'll just bring a laptop along:
> free WiFi.

Yeah, this should work. After you've pulled the tree, the updates are not that
bad.

>> Of course you can also keep using -hg.
> 
> That was my plan.
> 
> Regards,
> Andy
> 
>> Cheers,
>> Mauro
> 

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Markus Heidelberg wrote:
> Mauro Carvalho Chehab, 2010-01-19:
>> Yes. I personally prefer to have a bare clone (bare trees have just
>> the -git objects, and not a workig tree), and several working copies.
>> I do the work at the working copies, and, after they are fine, I push
>> into the bare and send the branches from bare to upstream.
> 
> Do you know git-new-workdir? It's included in the contrib area of the
> git installation.
> Instead of cloning your own local repository to get a new working
> directory, with this script you really only get a new working directory
> and can work in it as if it was the original clone. Then you don't have
> to deal with pushes between local repositories.

No, I never used. Sometimes, I use to manually create a new workdir copy,
but it is good to know that there's an script ready for doing this.

Thanks for pointing it!

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Hans Verkuil wrote:
>>> 	4) v4l2-apps - I agree that splitting it could be a good idea, provided
>>> that we find
>>> a way to handle the few cases where we have "example" applications at
>>> the media docs.
>> Note that v4l2-apps also contains libv4l, it so happens that I've been
>> discussing moving
>> libv4l to its own git tree with Brandon Philips. Preferably to a place
>> which also offers
>> some form of bug tracking. The advantages of having libv4l in its own tree
>> are:
>>
>> -it is maintained independent of the hg tree anyways
>> -it has regular versioned tarbal releases, it would be good to be able to
>> tag these
>>   inside the used scm, which is hard to do when the scm is shared with
>> other unrelated
>>   code which does not end up in said tarballs
>> -this means having a much smaller tree making it easier to clone
>> -no longer having an often old (stale) libv4l in the master hg repository
>>   (this is partially my fault as I should send pull requests for libv4l
>> moe often,
>>    but why all this synchronization overhead when its independent anyways)
>>
>> As said when discussing this with Brandon we were thinking about using
>> something
>> like github, as that offers bug tracking too. But I can understand if you
>> would prefer
>> to keep libv4l at linuxtv.org .

Hans G.,

I prefer to keep it at linuxtv.org, and together with v4l2-apps. The rationale
is that there are applications that are dependent on libv4l (like v4l2grab).
We're also about to commit a gtk webcam application based on libv4l. So, IMO,
the better is to keep all of those applications together.

As we're discussing about having a separate tree for v4l2-apps, maybe the better
is to port it to -git (in a way that we can preserve the log history).

>>
>> The last few fays I've been working on making a stand alone version of the
>> uvcdynctrl
>> tool, which is meant to send a userspace database of vendor specific
>> controls to
>> the uvcvideo driver, after which they will show up as regular v4l2
>> controls.
>>
>> The uvcdynctrl utility is part of the libwebcam project:
>> http://www.quickcamteam.net/software/libwebcam
>>
>> But given that libwebcam is unmaintained and not used by anything AFAIK,
>> I'm patching
>> uvcdynctrl to no longer need it. The plan is to add uvcdynctrl to libv4l
>> soon, as that
>> is needed to be able to control the focus on some uvc autofocus cameras.
>>
>> This means that libv4l will be growing a set of utilities, currently just
>> uvcdynctrl
>> (and its database and udev scripts), but given this precedent we could add
>> more
>> utilities to libv4l. I wouldn't mind moving v4l2-ctl and v4l2-dbg to
>> libv4l, this would
>> also have the advantage that since most distro's ship libv4l these
>> utilities would
>> actually become available to end users (which AFAIK currently they are not
>> in most
>> distros).

IMO, we should not mix libv4l with the applications that use libv4l. It is good
to have separate dirs for different things, like what we currently have under
v4l2-apps.
 
> It seems to me that creating a v4l2-apps tree (similar to dvb-apps) would
> solve most of these issues

Agreed.

> (except for bug tracking).

Well, I don't see why not adding a bug tracking system for v4l2-apps an dvb-apps,
if needed. Are you thinking on something specific?

> We would need to do
> some rearranging in the directory structure of v4l2-apps, though.

Yes. Maybe we can move the tools that aren't meant to be used on distros on a separate
dir, like contrib, having a separate make install for building them.

Also, we need to use some config tool like autoconf that will seek for dependencies
and or require the needed ones or not compile the applications that depends on some
library.

> It is a bit of a mix of production code like libv4l and v4l2-ctl, v4l2-dbg.
> cx18-ctl and ivtv-ctl, and more test or debug oriented tools. The latter
> do not need to be packaged by distros.

Yes.

> Personally I would prefer to keep v4l2-apps on linuxtv.org. But the strict
> commit procedure that we have for the main v4l-dvb repo can be relaxed
> here. 

What do you mean by a "relaxed" one? Currently, there's no defined procedure for 
the applications there: several different CodingStyles were used on the different 
applications and no standard criteria were used to ack/nack changes there.

IMO, we should go on the opposite direction: we need to have some standard rules
also for it (but, it can be more relaxed than what we have in kernel).

For sure, one rule we need to define is what criteria will be used to classify
an application as something that will be compiled/installed by default, and what
applications are development-oriented applications. On some cases, this is clear
(for example, the API compliance test applications are developer-oriented, while
libv4l is a standard user-oriented one). However, a debug application (like v4l2-dbg)
is a development application, but it may be nice to have it available at the
distros, to help users to help check/report problems).

It may also be useful to define a minimum set of coding style, like how applications
should be indented 

> So it should be possible for you to have commit rights so you can
> use it as your master repository.

Maybe the better owner for v4l2-apps would be Hans G., since most of the changes there
are related to libv4l.

On the experiences we had with v4l-dvb tree, it is not a good idea to allow multiple
people to commit at the master repository, since, when a conflict rises between two
different developers, this can cause lots of heat. Also, it is easy to corrupt a tree,
as a push with -f flag can remove (or hide, on -git) the objects inserted by someone else.

So, IMO, every tree should have a single owner.

> Mauro, what do you think?

See above.

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede]

Hi,

On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
>>>> 	4) v4l2-apps - I agree that splitting it could be a good idea, provided
>>>> that we find
>>>> a way to handle the few cases where we have "example" applications at
>>>> the media docs.
>>> Note that v4l2-apps also contains libv4l, it so happens that I've been
>>> discussing moving
>>> libv4l to its own git tree with Brandon Philips. Preferably to a place
>>> which also offers
>>> some form of bug tracking. The advantages of having libv4l in its own tree
>>> are:
>>>
>>> -it is maintained independent of the hg tree anyways
>>> -it has regular versioned tarbal releases, it would be good to be able to
>>> tag these
>>>    inside the used scm, which is hard to do when the scm is shared with
>>> other unrelated
>>>    code which does not end up in said tarballs
>>> -this means having a much smaller tree making it easier to clone
>>> -no longer having an often old (stale) libv4l in the master hg repository
>>>    (this is partially my fault as I should send pull requests for libv4l
>>> moe often,
>>>     but why all this synchronization overhead when its independent anyways)
>>>
>>> As said when discussing this with Brandon we were thinking about using
>>> something
>>> like github, as that offers bug tracking too. But I can understand if you
>>> would prefer
>>> to keep libv4l at linuxtv.org .
>
> Hans G.,
>
> I prefer to keep it at linuxtv.org, and together with v4l2-apps. The rationale
> is that there are applications that are dependent on libv4l (like v4l2grab).
> We're also about to commit a gtk webcam application based on libv4l. So, IMO,
> the better is to keep all of those applications together.
>
> As we're discussing about having a separate tree for v4l2-apps, maybe the better
> is to port it to -git (in a way that we can preserve the log history).
>

Having a separate tree for v4l2-apps would work for me. If possible with direct
commit / push rights, given that I'm doing 90% of the libv4l work.

>> (except for bug tracking).
>
> Well, I don't see why not adding a bug tracking system for v4l2-apps an dvb-apps,
> if needed. Are you thinking on something specific?
>

If I can put in wishes I would like bugzilla :)

>> We would need to do
>> some rearranging in the directory structure of v4l2-apps, though.
>
> Yes. Maybe we can move the tools that aren't meant to be used on distros on a separate
> dir, like contrib, having a separate make install for building them.
>
> Also, we need to use some config tool like autoconf that will seek for dependencies
> and or require the needed ones or not compile the applications that depends on some
> library.
>

Ugh, I'm no fan of autoconf, but I can see this being handy, any volunteers for
doing this bit ?

>> It is a bit of a mix of production code like libv4l and v4l2-ctl, v4l2-dbg.
>> cx18-ctl and ivtv-ctl, and more test or debug oriented tools. The latter
>> do not need to be packaged by distros.
>
> Yes.
>
>> Personally I would prefer to keep v4l2-apps on linuxtv.org. But the strict
>> commit procedure that we have for the main v4l-dvb repo can be relaxed
>> here.
>
> What do you mean by a "relaxed" one? Currently, there's no defined procedure for
> the applications there: several different CodingStyles were used on the different
> applications and no standard criteria were used to ack/nack changes there.
>
> IMO, we should go on the opposite direction: we need to have some standard rules
> also for it (but, it can be more relaxed than what we have in kernel).
>

Ack, we need to at least have rules, like should build on a modern distro
without issues (if the deps are there), etc.

> For sure, one rule we need to define is what criteria will be used to classify
> an application as something that will be compiled/installed by default, and what
> applications are development-oriented applications. On some cases, this is clear
> (for example, the API compliance test applications are developer-oriented, while
> libv4l is a standard user-oriented one). However, a debug application (like v4l2-dbg)
> is a development application, but it may be nice to have it available at the
> distros, to help users to help check/report problems).
>

Ack, I too think having v4l2-dbg available to end users could come in very handy to
remote debug stuff.

> It may also be useful to define a minimum set of coding style, like how applications
> should be indented
>
>> So it should be possible for you to have commit rights so you can
>> use it as your master repository.
>
> Maybe the better owner for v4l2-apps would be Hans G., since most of the changes there
> are related to libv4l.
>

I wouldn't mind giving this a try.

> On the experiences we had with v4l-dvb tree, it is not a good idea to allow multiple
> people to commit at the master repository, since, when a conflict rises between two
> different developers, this can cause lots of heat. Also, it is easy to corrupt a tree,
> as a push with -f flag can remove (or hide, on -git) the objects inserted by someone else.
>

I've different experience in the projects with git I've used, as long as there are some
governance rules (like never ever push -f, always do a rebase fix your stuff and then
push, and if something else got in in the window in between rebase again, etc.).

Regards,

Hans

Re: [ANNOUNCE] git tree repositories

[Guennadi Liakhovetski]

Thank you, Mauro, for doing this work! It is highly appreciated!

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [ANNOUNCE] git tree repositories & libv4l

[Brandon Philips]

On 19:50 Wed 20 Jan 2010, Hans de Goede wrote:
> On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote:
> >As we're discussing about having a separate tree for v4l2-apps,
> >maybe the better is to port it to -git (in a way that we can
> >preserve the log history).

I have a small script I used to convert the history of libv4l to
git. Let me know when we are ready to drop them from the hg tree and I
can do the conversion and post the result for review.

This is the result from the script for just libv4l:
 http://ifup.org/git/?p=libv4l.git;a=summary

Also, I suggest we call the repo v4lutils? In the spirit of usbutils,
pciutils, etc.

> Having a separate tree for v4l2-apps would work for me. If possible
> with direct commit / push rights, given that I'm doing 90% of the
> libv4l work.

I am fine with Hans doing this. Thanks Hans.

> >>We would need to do
> >>some rearranging in the directory structure of v4l2-apps, though.
> >
> >Yes. Maybe we can move the tools that aren't meant to be used on distros on a separate
> >dir, like contrib, having a separate make install for building them.
> >
> >Also, we need to use some config tool like autoconf that will seek
> >for dependencies and or require the needed ones or not compile the
> >applications that depends on some library.
> >
> 
> Ugh, I'm no fan of autoconf, but I can see this being handy, any volunteers for
> doing this bit ?

I started getting libv4l converted to autoconf earlier. If you are OK
with it I can provide patches after we get the repo converted.

> >For sure, one rule we need to define is what criteria will be used
> >to classify an application as something that will be
> >compiled/installed by default, and what applications are
> >development-oriented applications. On some cases, this is clear
> >(for example, the API compliance test applications are
> >developer-oriented, while libv4l is a standard user-oriented
> >one). However, a debug application (like v4l2-dbg) is a development
> >application, but it may be nice to have it available at the
> >distros, to help users to help check/report problems).
> 
> Ack, I too think having v4l2-dbg available to end users could come
> in very handy to remote debug stuff.

Indeed. Any tools that allow us to get insight would be great. Our
current debugging tool belt is pretty poor in a lot of cases: lsusb,
lspci, dmesg, "does cheese work"?

> >It may also be useful to define a minimum set of coding style, like
> >how applications should be indented

Adopting Documentation/CodingStyle from the kernel with a few tweaks
should work. That way we could use existing infrastructure like
checkpatch.pl to check incoming stuff out.

Shall we just go through and convert everything at once then? Bulk
coding style conversions with cstyle, etc never works 100% and so
someone will need to review the diffs by hand. Volunteers with
experience doing that?

> >On the experiences we had with v4l-dvb tree, it is not a good idea
> >to allow multiple people to commit at the master repository, since,
> >when a conflict rises between two different developers, this can
> >cause lots of heat. Also, it is easy to corrupt a tree, as a push
> >with -f flag can remove (or hide, on -git) the objects inserted by
> >someone else.
> >
> 
> I've different experience in the projects with git I've used, as
> long as there are some governance rules (like never ever push -f,
> always do a rebase fix your stuff and then push, and if something
> else got in in the window in between rebase again, etc.).

If the group of people with commit access is small (3-4) it generally
works well.

Cheers,

	Brandon

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Brandon Philips wrote:
> On 19:50 Wed 20 Jan 2010, Hans de Goede wrote:
>> On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote:
>>> As we're discussing about having a separate tree for v4l2-apps,
>>> maybe the better is to port it to -git (in a way that we can
>>> preserve the log history).
> 
> I have a small script I used to convert the history of libv4l to
> git. Let me know when we are ready to drop them from the hg tree and I
> can do the conversion and post the result for review.
> 
> This is the result from the script for just libv4l:
>  http://ifup.org/git/?p=libv4l.git;a=summary

Seems fine, but we need to import the entire v4l2-apps.

> Also, I suggest we call the repo v4lutils? In the spirit of usbutils,
> pciutils, etc.

Hmm... as dvb package is called as dvb-utils, it seems more logical to call it
v4l2-utils, but v4l2utils would equally work.

IMO, the better is to use v4l2 instead of just v4l, to avoid causing any
mess with the old v4l applications provided with xawtv.
> 
>> Having a separate tree for v4l2-apps would work for me. If possible
>> with direct commit / push rights, given that I'm doing 90% of the
>> libv4l work.
> 
> I am fine with Hans doing this. Thanks Hans.

Ok.
> 
>>>> We would need to do
>>>> some rearranging in the directory structure of v4l2-apps, though.
>>> Yes. Maybe we can move the tools that aren't meant to be used on distros on a separate
>>> dir, like contrib, having a separate make install for building them.
>>>
>>> Also, we need to use some config tool like autoconf that will seek
>>> for dependencies and or require the needed ones or not compile the
>>> applications that depends on some library.
>>>
>> Ugh, I'm no fan of autoconf, but I can see this being handy, any volunteers for
>> doing this bit ?
> 
> I started getting libv4l converted to autoconf earlier. If you are OK
> with it I can provide patches after we get the repo converted.

Seems good enough for me.

>>> For sure, one rule we need to define is what criteria will be used
>>> to classify an application as something that will be
>>> compiled/installed by default, and what applications are
>>> development-oriented applications. On some cases, this is clear
>>> (for example, the API compliance test applications are
>>> developer-oriented, while libv4l is a standard user-oriented
>>> one). However, a debug application (like v4l2-dbg) is a development
>>> application, but it may be nice to have it available at the
>>> distros, to help users to help check/report problems).
>> Ack, I too think having v4l2-dbg available to end users could come
>> in very handy to remote debug stuff.
> 
> Indeed. Any tools that allow us to get insight would be great. Our
> current debugging tool belt is pretty poor in a lot of cases: lsusb,
> lspci, dmesg, "does cheese work"?
> 
>>> It may also be useful to define a minimum set of coding style, like
>>> how applications should be indented
> 
> Adopting Documentation/CodingStyle from the kernel with a few tweaks
> should work. That way we could use existing infrastructure like
> checkpatch.pl to check incoming stuff out.

Yes, but, as we have also non-c code, some rules there don't apply.
For example the rationale for not using // comments don't apply to c++, 
since it is there since the first definition.

> Shall we just go through and convert everything at once then? Bulk
> coding style conversions with cstyle, etc never works 100% and so
> someone will need to review the diffs by hand. Volunteers with
> experience doing that?

I have no strong opinion if we should or not convert the code to some
codingstyle, but, if we do, the better is to do everything at once.

>>> On the experiences we had with v4l-dvb tree, it is not a good idea
>>> to allow multiple people to commit at the master repository, since,
>>> when a conflict rises between two different developers, this can
>>> cause lots of heat. Also, it is easy to corrupt a tree, as a push
>>> with -f flag can remove (or hide, on -git) the objects inserted by
>>> someone else.
>>>
>> I've different experience in the projects with git I've used, as
>> long as there are some governance rules (like never ever push -f,
>> always do a rebase fix your stuff and then push, and if something
>> else got in in the window in between rebase again, etc.).
> 
> If the group of people with commit access is small (3-4) it generally
> works well.

Yes. The more people touching at the same tree, the more troubles may happen.

I don't object to allow a limited group of people accessing it, although
I suspect that, if we open to more than one, we will have more than 4 people
interested on it.

Cheers,
Mauro.

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Johannes Stezenbach wrote:
> Hi,
> 
> may I humbly request to make it mandatory to enter a description
> when a user creates a new tree on linuxtv.org?
> IMHO "foobar development repository" isn't useful at all.

Ok, I changed the git-menu script to ask for the description before
creating the clone.

> If I look at http://linuxtv.org/hg/ many times I have no
> clue what a repo is about or why it exists at all.
> Let's not repeat the same mistake with git.

Agreed.

> OTOH, since with git it is common to have multiple branches
> within one repository, I'm not sure how it works. It would
> be cool if git would support per-branch descriptions,
> and git web could display them.

I don't think git supports it. In kernel.org, people prefer to
use more than one repository when they have more than one
need.

Cheers,
Mauro.

Re: [ANNOUNCE] git tree repositories & libv4l

[Brandon Philips]

On 00:07 Thu 21 Jan 2010, Mauro Carvalho Chehab wrote:
> Brandon Philips wrote:
> > On 19:50 Wed 20 Jan 2010, Hans de Goede wrote:
> >> On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote:
> >>> As we're discussing about having a separate tree for v4l2-apps,
> >>> maybe the better is to port it to -git (in a way that we can
> >>> preserve the log history).
> > 
> > I have a small script I used to convert the history of libv4l to
> > git. Let me know when we are ready to drop them from the hg tree
> > and I can do the conversion and post the result for review.
> > 
> > This is the result from the script for just libv4l:
> >  http://ifup.org/git/?p=libv4l.git;a=summary
> 
> Seems fine, but we need to import the entire v4l2-apps.

Yes, I know. I will run the script over v4l2-apps to generate a git
repo once v4l2-apps is ready to be dropped from v4l-dvb mercurial and
we figure out the directory layout.

Doing it before is just a waste of time since they will get out of
sync.

> > Also, I suggest we call the repo v4lutils? In the spirit of
> > usbutils, pciutils, etc.
> 
> Hmm... as dvb package is called as dvb-utils, it seems more logical to call it
> v4l2-utils, but v4l2utils would equally work.

Yes, that is fine.

> IMO, the better is to use v4l2 instead of just v4l, to avoid causing
> any mess with the old v4l applications provided with xawtv.

The problem I saw was that libv4l1 will be in v4l2-utils. I don't care
either way though.

So here is how I see v4l-utils.git being laid out based on what others
have said:

 libv4l1/
 libv4l2/
 libv4lconvert/
 test/
 v4l2-dbg/
 contrib/
  qv4l2-qt3/
  qv4l2-qt4/
  cx25821/
  etc... everything else

Are there things in v4l2-apps that should be imported? Other suggestions?

Cheers,

	Brandon

Re: [ANNOUNCE] git tree repositories

[Trent Piepho]

On Thu, 21 Jan 2010, Mauro Carvalho Chehab wrote:
> > OTOH, since with git it is common to have multiple branches
> > within one repository, I'm not sure how it works. It would
> > be cool if git would support per-branch descriptions,
> > and git web could display them.
>
> I don't think git supports it. In kernel.org, people prefer to
> use more than one repository when they have more than one
> need.

stgit lets me set descriptions for each branch.  The descriptions are there
under the branch in the config file.  I don't think git-branch shows any
kind of description for the branch.

Re: [ANNOUNCE] git tree repositories

[Mauro Carvalho Chehab]

Trent Piepho wrote:
> On Thu, 21 Jan 2010, Mauro Carvalho Chehab wrote:
>>> OTOH, since with git it is common to have multiple branches
>>> within one repository, I'm not sure how it works. It would
>>> be cool if git would support per-branch descriptions,
>>> and git web could display them.
>> I don't think git supports it. In kernel.org, people prefer to
>> use more than one repository when they have more than one
>> need.
> 
> stgit lets me set descriptions for each branch.  The descriptions are there
> under the branch in the config file.  I don't think git-branch shows any
> kind of description for the branch.
stgit is a very interesting git porcelain. I used it a lot when I started with git.
It were very useful at the time git weren't implementing tools like rebase. 

However, stgit produces objects that aren't referenced, generating errors when 
you run "git fsck". So, I don't recomend using stgit anymore.

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans Verkuil]

On Thursday 21 January 2010 03:07:32 Mauro Carvalho Chehab wrote:
> Brandon Philips wrote:
> > On 19:50 Wed 20 Jan 2010, Hans de Goede wrote:
> >> On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote:
> >>> As we're discussing about having a separate tree for v4l2-apps,
> >>> maybe the better is to port it to -git (in a way that we can
> >>> preserve the log history).
> > 
> > I have a small script I used to convert the history of libv4l to
> > git. Let me know when we are ready to drop them from the hg tree and I
> > can do the conversion and post the result for review.
> > 
> > This is the result from the script for just libv4l:
> >  http://ifup.org/git/?p=libv4l.git;a=summary
> 
> Seems fine, but we need to import the entire v4l2-apps.
> 
> > Also, I suggest we call the repo v4lutils? In the spirit of usbutils,
> > pciutils, etc.
> 
> Hmm... as dvb package is called as dvb-utils, it seems more logical to call it
> v4l2-utils, but v4l2utils would equally work.
> 
> IMO, the better is to use v4l2 instead of just v4l, to avoid causing any
> mess with the old v4l applications provided with xawtv.

I also prefer v4l2-utils. It certainly should start with v4l2, not just v4l.

> > 
> >> Having a separate tree for v4l2-apps would work for me. If possible
> >> with direct commit / push rights, given that I'm doing 90% of the
> >> libv4l work.
> > 
> > I am fine with Hans doing this. Thanks Hans.
> 
> Ok.
> > 
> >>>> We would need to do
> >>>> some rearranging in the directory structure of v4l2-apps, though.
> >>> Yes. Maybe we can move the tools that aren't meant to be used on distros on a separate
> >>> dir, like contrib, having a separate make install for building them.
> >>>
> >>> Also, we need to use some config tool like autoconf that will seek
> >>> for dependencies and or require the needed ones or not compile the
> >>> applications that depends on some library.
> >>>
> >> Ugh, I'm no fan of autoconf, but I can see this being handy, any volunteers for
> >> doing this bit ?
> > 
> > I started getting libv4l converted to autoconf earlier. If you are OK
> > with it I can provide patches after we get the repo converted.
> 
> Seems good enough for me.
> 
> >>> For sure, one rule we need to define is what criteria will be used
> >>> to classify an application as something that will be
> >>> compiled/installed by default, and what applications are
> >>> development-oriented applications. On some cases, this is clear
> >>> (for example, the API compliance test applications are
> >>> developer-oriented, while libv4l is a standard user-oriented
> >>> one). However, a debug application (like v4l2-dbg) is a development
> >>> application, but it may be nice to have it available at the
> >>> distros, to help users to help check/report problems).
> >> Ack, I too think having v4l2-dbg available to end users could come
> >> in very handy to remote debug stuff.
> > 
> > Indeed. Any tools that allow us to get insight would be great. Our
> > current debugging tool belt is pretty poor in a lot of cases: lsusb,
> > lspci, dmesg, "does cheese work"?
> > 
> >>> It may also be useful to define a minimum set of coding style, like
> >>> how applications should be indented
> > 
> > Adopting Documentation/CodingStyle from the kernel with a few tweaks
> > should work. That way we could use existing infrastructure like
> > checkpatch.pl to check incoming stuff out.
> 
> Yes, but, as we have also non-c code, some rules there don't apply.
> For example the rationale for not using // comments don't apply to c++, 
> since it is there since the first definition.

Most apps are already in 'kernel' style. The main exception being libv4l.

> 
> > Shall we just go through and convert everything at once then? Bulk
> > coding style conversions with cstyle, etc never works 100% and so
> > someone will need to review the diffs by hand. Volunteers with
> > experience doing that?
> 
> I have no strong opinion if we should or not convert the code to some
> codingstyle, but, if we do, the better is to do everything at once.

I agree.
 
> >>> On the experiences we had with v4l-dvb tree, it is not a good idea
> >>> to allow multiple people to commit at the master repository, since,
> >>> when a conflict rises between two different developers, this can
> >>> cause lots of heat. Also, it is easy to corrupt a tree, as a push
> >>> with -f flag can remove (or hide, on -git) the objects inserted by
> >>> someone else.
> >>>
> >> I've different experience in the projects with git I've used, as
> >> long as there are some governance rules (like never ever push -f,
> >> always do a rebase fix your stuff and then push, and if something
> >> else got in in the window in between rebase again, etc.).
> > 
> > If the group of people with commit access is small (3-4) it generally
> > works well.
> 
> Yes. The more people touching at the same tree, the more troubles may happen.
> 
> I don't object to allow a limited group of people accessing it, although
> I suspect that, if we open to more than one, we will have more than 4 people
> interested on it.

In practice the only people who regularly touch v4l2-apps are Hans de Goede
(libv4l), you and myself (v4l2-ctl, v4l2-dbg, qv4l2). I can't remember anyone
else contributing regularly to v4l2-apps.

Regards,

	Hans

> 
> Cheers,
> Mauro.
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans Verkuil]

On Thursday 21 January 2010 03:46:05 Brandon Philips wrote:
> On 00:07 Thu 21 Jan 2010, Mauro Carvalho Chehab wrote:
> > Brandon Philips wrote:
> > > On 19:50 Wed 20 Jan 2010, Hans de Goede wrote:
> > >> On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote:
> > >>> As we're discussing about having a separate tree for v4l2-apps,
> > >>> maybe the better is to port it to -git (in a way that we can
> > >>> preserve the log history).
> > > 
> > > I have a small script I used to convert the history of libv4l to
> > > git. Let me know when we are ready to drop them from the hg tree
> > > and I can do the conversion and post the result for review.
> > > 
> > > This is the result from the script for just libv4l:
> > >  http://ifup.org/git/?p=libv4l.git;a=summary
> > 
> > Seems fine, but we need to import the entire v4l2-apps.
> 
> Yes, I know. I will run the script over v4l2-apps to generate a git
> repo once v4l2-apps is ready to be dropped from v4l-dvb mercurial and
> we figure out the directory layout.
> 
> Doing it before is just a waste of time since they will get out of
> sync.
> 
> > > Also, I suggest we call the repo v4lutils? In the spirit of
> > > usbutils, pciutils, etc.
> > 
> > Hmm... as dvb package is called as dvb-utils, it seems more logical to call it
> > v4l2-utils, but v4l2utils would equally work.
> 
> Yes, that is fine.
> 
> > IMO, the better is to use v4l2 instead of just v4l, to avoid causing
> > any mess with the old v4l applications provided with xawtv.
> 
> The problem I saw was that libv4l1 will be in v4l2-utils. I don't care
> either way though.
> 
> So here is how I see v4l-utils.git being laid out based on what others
> have said:
> 
>  libv4l1/
>  libv4l2/
>  libv4lconvert/
>  test/
>  v4l2-dbg/
>  contrib/
>   qv4l2-qt3/
>   qv4l2-qt4/
>   cx25821/
>   etc... everything else

Hmm. I think I would prefer to have a structure like this:

lib/
	libv4l1/
	libv4l2/
	libv4lconvert/
utils/
	v4l2-dbg
	v4l2-ctl
	cx18-ctl
	ivtv-ctl
contrib/
	test/
	everything else

And everything in lib and utils can be packaged by distros, while contrib
is not packaged.

What would also be nice is if this project http://v4l-test.sourceforge.net/
could eventually be merged in v4l2-apps.

> 
> Are there things in v4l2-apps that should be imported? 

I'm sorry, but I'm not sure what you mean.

Regards,

	Hans

> Other suggestions?
> 
> Cheers,
> 
> 	Brandon
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Hans Verkuil wrote:
> On Thursday 21 January 2010 03:07:32 Mauro Carvalho Chehab wrote:
>> Brandon Philips wrote:

>>>> I've different experience in the projects with git I've used, as
>>>> long as there are some governance rules (like never ever push -f,
>>>> always do a rebase fix your stuff and then push, and if something
>>>> else got in in the window in between rebase again, etc.).
>>> If the group of people with commit access is small (3-4) it generally
>>> works well.
>> Yes. The more people touching at the same tree, the more troubles may happen.
>>
>> I don't object to allow a limited group of people accessing it, although
>> I suspect that, if we open to more than one, we will have more than 4 people
>> interested on it.
> 
> In practice the only people who regularly touch v4l2-apps are Hans de Goede
> (libv4l), you and myself (v4l2-ctl, v4l2-dbg, qv4l2). I can't remember anyone
> else contributing regularly to v4l2-apps.

It seems that you forgot me ;) After running the import proccess and have the
contributions isolated, it would be easy to double check if nobody else is missed.

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Hans Verkuil wrote:
> On Thursday 21 January 2010 03:46:05 Brandon Philips wrote:
>> On 00:07 Thu 21 Jan 2010, Mauro Carvalho Chehab wrote:
>>> Brandon Philips wrote:

>> So here is how I see v4l-utils.git being laid out based on what others
>> have said:
>>
>>  libv4l1/
>>  libv4l2/
>>  libv4lconvert/
>>  test/
>>  v4l2-dbg/
>>  contrib/
>>   qv4l2-qt3/
>>   qv4l2-qt4/
>>   cx25821/
>>   etc... everything else
> 
> Hmm. I think I would prefer to have a structure like this:
> 
> lib/
> 	libv4l1/
> 	libv4l2/
> 	libv4lconvert/

I don't have a strong opinion if we should have a /lib dir here or
not.

> utils/
> 	v4l2-dbg
> 	v4l2-ctl
> 	cx18-ctl
> 	ivtv-ctl

	keytable
	v4l2-sysfs-path
parsers/
	parse_em28xx.pl
	parse-sniffusb2.pl

> 	test/
> 	everything else

I like the idea of putting everything else under
	contrib/

> And everything in lib and utils can be packaged by distros, while contrib
> is not packaged.

With respect to the parsers (parse_em28xx.pl and parse-sniffusb2.pl), in practice, they
seemed more important than the v4l2-dbg, as they help to check what GPIO's are needed
to support the USB devices (and it is impractical to send us a non-parsed log, due to its
very long size). So, IMO, this should be installed on distros.

> What would also be nice is if this project http://v4l-test.sourceforge.net/
> could eventually be merged in v4l2-apps.

Agreed.

Cheers,
Mauro.

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede]

Hi all,

On 01/21/2010 08:34 AM, Hans Verkuil wrote:
> On Thursday 21 January 2010 03:46:05 Brandon Philips wrote:
>> On 00:07 Thu 21 Jan 2010, Mauro Carvalho Chehab wrote:
>>> Brandon Philips wrote:
>>>> On 19:50 Wed 20 Jan 2010, Hans de Goede wrote:
>>>>> On 01/20/2010 04:41 PM, Mauro Carvalho Chehab wrote:
>>>>>> As we're discussing about having a separate tree for v4l2-apps,
>>>>>> maybe the better is to port it to -git (in a way that we can
>>>>>> preserve the log history).
>>>>
>>>> I have a small script I used to convert the history of libv4l to
>>>> git. Let me know when we are ready to drop them from the hg tree
>>>> and I can do the conversion and post the result for review.
>>>>
>>>> This is the result from the script for just libv4l:
>>>>   http://ifup.org/git/?p=libv4l.git;a=summary
>>>
>>> Seems fine, but we need to import the entire v4l2-apps.
>>
>> Yes, I know. I will run the script over v4l2-apps to generate a git
>> repo once v4l2-apps is ready to be dropped from v4l-dvb mercurial and
>> we figure out the directory layout.
>>
>> Doing it before is just a waste of time since they will get out of
>> sync.
>>
>>>> Also, I suggest we call the repo v4lutils? In the spirit of
>>>> usbutils, pciutils, etc.
>>>
>>> Hmm... as dvb package is called as dvb-utils, it seems more logical to call it
>>> v4l2-utils, but v4l2utils would equally work.
>>
>> Yes, that is fine.
>>
>>> IMO, the better is to use v4l2 instead of just v4l, to avoid causing
>>> any mess with the old v4l applications provided with xawtv.
>>
>> The problem I saw was that libv4l1 will be in v4l2-utils. I don't care
>> either way though.
>>
>> So here is how I see v4l-utils.git being laid out based on what others
>> have said:
>>
>>   libv4l1/
>>   libv4l2/
>>   libv4lconvert/
>>   test/
>>   v4l2-dbg/
>>   contrib/
>>    qv4l2-qt3/
>>    qv4l2-qt4/
>>    cx25821/
>>    etc... everything else
>
> Hmm. I think I would prefer to have a structure like this:
>
> lib/
> 	libv4l1/
> 	libv4l2/
> 	libv4lconvert/
> utils/
> 	v4l2-dbg
> 	v4l2-ctl
> 	cx18-ctl
> 	ivtv-ctl
> contrib/
> 	test/
> 	everything else
>
> And everything in lib and utils can be packaged by distros, while contrib
> is not packaged.
>

+1 for this directory layout.

Regards,

Hans

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede]

Hi,

On 01/21/2010 08:23 AM, Hans Verkuil wrote:
>>

<snip>

>> Yes, but, as we have also non-c code, some rules there don't apply.
>> For example the rationale for not using // comments don't apply to c++,
>> since it is there since the first definition.
>
> Most apps are already in 'kernel' style. The main exception being libv4l.
>

Ack,

which in hind sight may not have been the best choice (I have no personal
coding style, I'm used to adjusting my style to what ever the project
I'm working on uses).

Still I would like to keep libv4l as an exception, re-indenting it is
not going to do it any good (I did my best to keep lines within 80
chars, but moving to tabs as indent will ruin this, and there are quite
a few nasty nested if cases in there).

<snip>

Regards,

Hans

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Hans de Goede wrote:
> Hi,
> 
> On 01/21/2010 08:23 AM, Hans Verkuil wrote:
>>>
> 
> <snip>
> 
>>> Yes, but, as we have also non-c code, some rules there don't apply.
>>> For example the rationale for not using // comments don't apply to c++,
>>> since it is there since the first definition.
>>
>> Most apps are already in 'kernel' style. The main exception being libv4l.

Well... they are "close" to kernel style, but if you run checkpatch over
all files there, I'm sure you'll see lots of violations.

> 
> Ack,
> 
> which in hind sight may not have been the best choice (I have no personal
> coding style, I'm used to adjusting my style to what ever the project
> I'm working on uses).
> 
> Still I would like to keep libv4l as an exception,

If we're adopting one CodingStyle, this should be done for everything, otherwise
it makes no sense to standardize.

> re-indenting it is
> not going to do it any good (I did my best to keep lines within 80
> chars, but moving to tabs as indent will ruin this, and there are quite
> a few nasty nested if cases in there).

The 80 chars limit is nowadays a "soft" simit. There are even some discussions from
people that the resulting code of people sending patches that just avoids the limit
is worse than before.

The idea behind this limit is that lines of code with more than 80 chars is an indication
that the code is more complex than it needs to be. So, the logic there may re-implemented
on a better way.

Just for fun, I ran this indent command (with kernel CodingStyle, except for the 80 chars
limit), over v4l2-apps/libv4l/libv4l2:

	indent -npro -kr -i8 -ts8 -sob  -ss -ncs -cp1  -l260 *.c

Except for one or two things, the resulting code seems a way better. Yet, as pointed by
Brandon, some manual work is needed to fix some parts of the result, as the indent is not
perfect.

Again for fun, I ran a checkpatch over the resulting code, removing all warnings due
to 80 cols (see enclosed). I think the troubles with the goto labels were introduced by
indent.

---

>From my side, it would be better to use the same CodingStyle also at v4l2-apps,
since this makes easier for people to contribute on both kernel and userspace. Also, 
I can read the code faster when it uses the Kernel CodingStyle.

Yet, not all checkpatch warnings apply to userspace, as some are specific to usage
of kernel deprecated functions. That's said, by using an style close to the kernel one,
it is easy to remove from checkpatch the warnings that won't apply to userspace.


Cheers,
Mauro

-

/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((result = SYS_IOCTL(devices[index].fd, VIDIOC_REQBUFS, &req)) < 0) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:102: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '		if ((result = SYS_IOCTL(devices[index].fd, VIDIOC_STREAMON, &type))) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:193: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((result = SYS_IOCTL(devices[index].fd, VIDIOC_QBUF, &buf))) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:238: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((result = v4l2_map_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:255: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '		if ((result = SYS_IOCTL(devices[index].fd, VIDIOC_DQBUF, buf))) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:259: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	}':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:287: warning: braces {} are not necessary for single statement blocks
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	}':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:338: warning: braces {} are not necessary for single statement blocks
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((result = v4l2_request_read_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:377: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((result = v4l2_map_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:380: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((result = v4l2_queue_read_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:383: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((result = v4l2_streamoff(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:395: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if (!v4l2_log_file && (lfname = getenv("LIBV4L2_LOG_FILENAME")))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:493: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if (!(convert = v4lconvert_create(fd)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:518: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((index = v4l2_get_index(fd)) == -1)':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:601: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((index = v4l2_get_index(fd)) == -1)':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:648: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((index = v4l2_get_index(fd)) == -1)':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:718: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '			if ((result = v4l2_check_buffer_change_ok(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:897: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '			if ((result = v4l2_check_buffer_change_ok(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:942: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '				if ((result = v4l2_deactivate_read_stream(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:964: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '			if ((result = v4l2_deactivate_read_stream(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:984: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '			if ((result = v4l2_map_buffers(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:989: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '				if ((result = v4l2_deactivate_read_stream(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:1000: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '			if ((result = v4l2_deactivate_read_stream(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:1046: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((index = v4l2_get_index(fd)) == -1)':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:1074: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '		if ((result = v4l2_activate_read_stream(index)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:1095: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '      leave:':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:1113: warning: labels should not be indented
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((index = v4l2_get_index(fd)) == -1 ||':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:1125: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '      leave:':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:1168: warning: labels should not be indented
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((index = v4l2_get_index(fd)) == -1) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:1221: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((result = v4lconvert_vidioc_queryctrl(devices[index].convert, &qctrl)))':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:1227: ERROR: do not use assignment in if condition
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c: In '	if ((index = v4l2_get_index(fd)) == -1) {':
/home/v4l/master/v4l2-apps/libv4l/libv4l2/libv4l2.c:1248: ERROR: do not use assignment in if condition

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede]

Hi,

On 01/24/2010 01:42 AM, Mauro Carvalho Chehab wrote:
> Hans de Goede wrote:
>> Hi,
>>
>> On 01/21/2010 08:23 AM, Hans Verkuil wrote:
>>>>
>>
>> <snip>
>>
>>>> Yes, but, as we have also non-c code, some rules there don't apply.
>>>> For example the rationale for not using // comments don't apply to c++,
>>>> since it is there since the first definition.
>>>
>>> Most apps are already in 'kernel' style. The main exception being libv4l.
>
> Well... they are "close" to kernel style, but if you run checkpatch over
> all files there, I'm sure you'll see lots of violations.
>
>>
>> Ack,
>>
>> which in hind sight may not have been the best choice (I have no personal
>> coding style, I'm used to adjusting my style to what ever the project
>> I'm working on uses).
>>
>> Still I would like to keep libv4l as an exception,
>
> If we're adopting one CodingStyle, this should be done for everything, otherwise
> it makes no sense to standardize.
>

Ok that makes sense. But as said this need to be done in one big bang commit then.

Regards,

Hans

Re: [ANNOUNCE] git tree repositories & libv4l

[Brandon Philips]

On 18:24 Sat 23 Jan 2010, Hans de Goede wrote:
> >lib/
> >	libv4l1/
> >	libv4l2/
> >	libv4lconvert/
> >utils/
> >	v4l2-dbg
> >	v4l2-ctl
> >	cx18-ctl
> >	ivtv-ctl
> >contrib/
> >	test/
> >	everything else
> >

  git clone git://ifup.org/philips/create-v4l-utils.git
  cd create-v4l-utils/
  ./convert.sh 

You should now have v4l-utils.git which should have this directory
struture. If we need to move other things around let me know and I can
tweak name-filter.sh

Thoughts? Let me know how we should proceed with dropping v4l2-apps
from v4l-dvb.

Re: code style cleanup. I think we should do that once we drop
v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream.

Cheers,

	Brandon

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans Verkuil]

On Monday 22 February 2010 23:54:26 Brandon Philips wrote:
> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote:
> > >lib/
> > >	libv4l1/
> > >	libv4l2/
> > >	libv4lconvert/
> > >utils/
> > >	v4l2-dbg
> > >	v4l2-ctl
> > >	cx18-ctl
> > >	ivtv-ctl
> > >contrib/
> > >	test/
> > >	everything else
> > >
> 
>   git clone git://ifup.org/philips/create-v4l-utils.git
>   cd create-v4l-utils/
>   ./convert.sh 
> 
> You should now have v4l-utils.git which should have this directory
> struture. If we need to move other things around let me know and I can
> tweak name-filter.sh
> 
> Thoughts? Let me know how we should proceed with dropping v4l2-apps
> from v4l-dvb.
> 
> Re: code style cleanup. I think we should do that once we drop
> v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream.

Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was
merged into dvb-apps, but while that tool supports dvb, it also supports
v4l2. Just like we merged dvb and v4l in a single repository, so I think we
should also merge the tools to a media-utils repository.

It remains a fact of life that dvb and v4l are connected and trying to
artificially keep them apart does not make much sense to me.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: [ANNOUNCE] git tree repositories & libv4l

[Brandon Philips]

On 00:26 Tue 23 Feb 2010, Hans Verkuil wrote:
> On Monday 22 February 2010 23:54:26 Brandon Philips wrote:
> > On 18:24 Sat 23 Jan 2010, Hans de Goede wrote:
> > > >lib/
> > > >	libv4l1/
> > > >	libv4l2/
> > > >	libv4lconvert/
> > > >utils/
> > > >	v4l2-dbg
> > > >	v4l2-ctl
> > > >	cx18-ctl
> > > >	ivtv-ctl
> > > >contrib/
> > > >	test/
> > > >	everything else
> > > >
> > 
> >   git clone git://ifup.org/philips/create-v4l-utils.git
> >   cd create-v4l-utils/
> >   ./convert.sh 
> > 
> > You should now have v4l-utils.git which should have this directory
> > struture. If we need to move other things around let me know and I can
> > tweak name-filter.sh
> > 
> > Thoughts? Let me know how we should proceed with dropping v4l2-apps
> > from v4l-dvb.
> > 
> > Re: code style cleanup. I think we should do that once we drop
> > v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream.
> 
> Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was
> merged into dvb-apps, but while that tool supports dvb, it also supports
> v4l2. Just like we merged dvb and v4l in a single repository, so I think we
> should also merge the tools to a media-utils repository.
> 
> It remains a fact of life that dvb and v4l are connected and trying to
> artificially keep them apart does not make much sense to me.

Easy to do but who should be the maintainer of the dvb things?

According to the wiki[1] these tools are without a maintainer. So, if
no one cares about them enough to make releases why merge them and
clutter up the git tree with dead code?

Cheers,

	Brandon

[1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Brandon Philips wrote:
> On 00:26 Tue 23 Feb 2010, Hans Verkuil wrote:
>> On Monday 22 February 2010 23:54:26 Brandon Philips wrote:
>>> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote:
>>>>> lib/
>>>>> 	libv4l1/
>>>>> 	libv4l2/
>>>>> 	libv4lconvert/
>>>>> utils/
>>>>> 	v4l2-dbg
>>>>> 	v4l2-ctl
>>>>> 	cx18-ctl
>>>>> 	ivtv-ctl
>>>>> contrib/
>>>>> 	test/
>>>>> 	everything else
>>>>>
>>>   git clone git://ifup.org/philips/create-v4l-utils.git
>>>   cd create-v4l-utils/
>>>   ./convert.sh 
>>>
>>> You should now have v4l-utils.git which should have this directory
>>> struture. If we need to move other things around let me know and I can
>>> tweak name-filter.sh
>>>
>>> Thoughts? Let me know how we should proceed with dropping v4l2-apps
>>> from v4l-dvb.
>>>
>>> Re: code style cleanup. I think we should do that once we drop
>>> v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream.
>> Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was
>> merged into dvb-apps, but while that tool supports dvb, it also supports
>> v4l2. Just like we merged dvb and v4l in a single repository, so I think we
>> should also merge the tools to a media-utils repository.
>>
>> It remains a fact of life that dvb and v4l are connected and trying to
>> artificially keep them apart does not make much sense to me.
> 
> Easy to do but who should be the maintainer of the dvb things?
> 
> According to the wiki[1] these tools are without a maintainer. So, if
> no one cares about them enough to make releases why merge them and
> clutter up the git tree with dead code?
> 
> Cheers,
> 
> 	Brandon
> 
> [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps

That's weird. I've recently added support for ISDB-T on it:
	http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/

and we've got some comments at the mailing list. Btw, the patches
I added there also adds DVB-S2 support to szap/scan, but tests
are needed, since I don't have any satellite dish nowadays.

-- 

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Mauro Carvalho Chehab wrote:
>> According to the wiki[1] these tools are without a maintainer. So, if
>> no one cares about them enough to make releases why merge them and
>> clutter up the git tree with dead code?
>>
>> [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps
> 
> That's weird. I've recently added support for ISDB-T on it:
> 	http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/
> 
> and we've got some comments at the mailing list. Btw, the patches
> I added there also adds DVB-S2 support to szap/scan, but tests
> are needed, since I don't have any satellite dish nowadays.
> 

Hmm... this got changed on Jun, 2009:

http://www.linuxtv.org/wiki/index.php?title=LinuxTV_dvb-apps&diff=prev&oldid=23404

Let me comment the "TODO" list:

    * Start numbering the versions. Yes, with a repo every commit is a kind of version, but in the real world of 
      distros and end users you need to define version numbers as easy reference points.
    * Tag versioned releases and make src tarballs for the distros.

By merging with v4l2-apps, those to will be easily handled.

    * Add ChangeLog and TODO files (and keep them up to date of course).

ChangeLog? Git history is better than it. A TODO file is useful only when there
are missing features.

    * Review the names of the apps and change where necessary. Perhaps scan is too ambiguous a name in a
 	general-purpose system where all sorts of things can be scanned 
	(with scanners, fax machines, barcode readers, etc.).

I agree. All distros I know renamed scan to dvbscan. This is a trivial patch through.

    * Implement API version 5 scanning and zapping for DVB-S2 channels. See S2API, scan-s2 and szap-s2.

It is done on my tree: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/
I still need to review Manu's comments on it. My intention is to do it after
the next merge window. Also, there are some DVB-S2 parameters that aren't present
at the channels.conf format. Nothing more complex than adding printf/scanf lines on
some files.

    * Improve the channels.conf file format so that one file can represent all the channels. Need to
          o (a) identify the source (S13.0E, S19.2E, Terrestrial, etc)
          o (b) identify the delivery system (DVB-S, DVB-S2, DVB-T etc)
          o (c) be able to represent all the parameters required for all the delivery systems
		 in a unified way. For example DVB-S2 has some new paramters (e.g. rolloff). 
		The "VDR" format was expanded for this, but in a messy way. 
    * Make sure there is one true format -- no "zap" versus "VDR" format confusion.
    * Merge all the *zap programs. You unified the channels.conf file so this is next. 

Changing the channels.conf format is easy. I had to do it for ISDB-T. The hard part is that
channels.conf is used on several DTV applications (mplayer, VDR, kaffeine, ...). So, any format
change will require changes on all applications that use channels.conf. This will be needed 
anyway, in order to add all features that are present on DVB-S2, and to
add ISDB-T format to the players. So, maybe someone can propose a "version 3" format (assuming
that VDR and ZAP are versions 1 and 2) that will be used by all applications.

That's said, if all the issues are the ones listed above, I can try to address them on the next
months, to put it into a better shape. That's said, I don't think we should have a single
maintainer for it: there are too many DTV standards already, and probably nobody with enough
time has access to all of those (DVB-T, DVB-T2, DVB-S, DVB-S2, ISDB-T, ISDB-S, ATSC, DSS, ...).
So, I think we need a team of volunteers that will try to help with the standards they have
access.

For the channels/transponders list, Christopher (kaffeine maintainer) is doing a really great
job. Maybe he could help with the last TODO items (e. g. helping to define the better format
for the channels.conf output).

That's said, I'm starting to agree with Hans: maybe the better seems to merge it with
v4l2-apps, to get synergy in terms, at least in terms of packet management.

Comments?

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Brandon Philips]

On 22:12 Mon 22 Feb 2010, Mauro Carvalho Chehab wrote:
> Mauro Carvalho Chehab wrote:
> >> According to the wiki[1] these tools are without a maintainer. So, if
> >> no one cares about them enough to make releases why merge them and
> >> clutter up the git tree with dead code?
> >>
> >> [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps
> > 
> > That's weird. I've recently added support for ISDB-T on it:
> > 	http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/
> > 
> > and we've got some comments at the mailing list. Btw, the patches
> > I added there also adds DVB-S2 support to szap/scan, but tests
> > are needed, since I don't have any satellite dish nowadays.
> > 
> 
> That's said, if all the issues are the ones listed above, I can try
> to address them on the next months, to put it into a better
> shape. That's said, I don't think we should have a single maintainer
> for it: there are too many DTV standards already, and probably
> nobody with enough time has access to all of those (DVB-T, DVB-T2,
> DVB-S, DVB-S2, ISDB-T, ISDB-S, ATSC, DSS, ...).  So, I think we need
> a team of volunteers that will try to help with the standards they
> have access.

I was not suggesting a single maintainer but I wanted to make sure
there was actual interest in maintaing and fixing these dvb things. I
don't interact much at all with DVB so all I had to go on was the wiki
page.

> That's said, I'm starting to agree with Hans: maybe the better seems
> to merge it with v4l2-apps, to get synergy in terms, at least in
> terms of packet management.
> 
> Comments?

Seems reasonable to me. I would be willing to be the merge point for
all of the various maintainers of dvb and v4l things and release
manager for making the actual tar.gz releases.

I wrote up the conversion for dvb-apps too. The merge of the two trees
conflict pretty trivially so it should be easy to clean up if we go
this route:

#	unmerged:   COPYING
#	unmerged:   INSTALL
#	unmerged:   Make.rules
#	unmerged:   Makefile
#	unmerged:   README
#	unmerged:   lib/Makefile
#	unmerged:   utils/Makefile

If you want to give it a whirl.

  git clone git://ifup.org/philips/create-v4l-utils.git
  cd create-v4l-utils/
  git checkout -b dvb-apps-too origin/dvb-apps-too
  ./convert.sh 

The result will be in step3 with the merge conflicts.

Cheers,

	Brandon

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede]

Hi,

On 02/22/2010 11:54 PM, Brandon Philips wrote:
> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote:
>>> lib/
>>> 	libv4l1/
>>> 	libv4l2/
>>> 	libv4lconvert/
>>> utils/
>>> 	v4l2-dbg
>>> 	v4l2-ctl
>>> 	cx18-ctl
>>> 	ivtv-ctl
>>> contrib/
>>> 	test/
>>> 	everything else
>>>
>
>    git clone git://ifup.org/philips/create-v4l-utils.git
>    cd create-v4l-utils/
>    ./convert.sh
>
> You should now have v4l-utils.git which should have this directory
> struture. If we need to move other things around let me know and I can
> tweak name-filter.sh
>

Ok, so this will give me a local tree, how do I get this onto linuxtv.org ?

Also I need someone to pull:
http://linuxtv.org/hg/~hgoede/libv4l

(this only contains libv4l commits)

Into the:
http://linuxtv.org/hg/v4l-dvb

Repository, I guess I can ask this directly to Douglas?

> Thoughts?

I've one question, I think we want to do tarbal releases
from this new repo (just like I've been doing with libv4l for a while
already), and then want distro's to pick up these releases, right ?

Are we going to do separate tarbals for the lib and utils directories,
or one combined tarbal. I personally vote for one combined tarbal.

But this means we will be inflicting some pains on distro's because their
libv4l packages will go away and be replaced by a new v4l-utils package.
This is something distro's should be able to handle (it happens more often, and I
know Fedora has procedures for this).

An alternative would be to name the repo and the tarbals libv4l, either is fine
with me (although I'm one of the distro packagers who is going to feel the pain
of a package rename and as such wouldn't mind using libv4l as name for the
repo and the new tarbals).

Regards,

Hans

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans Verkuil]

> Hi,
>
> On 02/22/2010 11:54 PM, Brandon Philips wrote:
>> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote:
>>>> lib/
>>>> 	libv4l1/
>>>> 	libv4l2/
>>>> 	libv4lconvert/
>>>> utils/
>>>> 	v4l2-dbg
>>>> 	v4l2-ctl
>>>> 	cx18-ctl
>>>> 	ivtv-ctl
>>>> contrib/
>>>> 	test/
>>>> 	everything else
>>>>
>>
>>    git clone git://ifup.org/philips/create-v4l-utils.git
>>    cd create-v4l-utils/
>>    ./convert.sh
>>
>> You should now have v4l-utils.git which should have this directory
>> struture. If we need to move other things around let me know and I can
>> tweak name-filter.sh
>>
>
> Ok, so this will give me a local tree, how do I get this onto linuxtv.org
> ?
>
> Also I need someone to pull:
> http://linuxtv.org/hg/~hgoede/libv4l
>
> (this only contains libv4l commits)
>
> Into the:
> http://linuxtv.org/hg/v4l-dvb
>
> Repository, I guess I can ask this directly to Douglas?
>
>> Thoughts?
>
> I've one question, I think we want to do tarbal releases
> from this new repo (just like I've been doing with libv4l for a while
> already), and then want distro's to pick up these releases, right ?
>
> Are we going to do separate tarbals for the lib and utils directories,
> or one combined tarbal. I personally vote for one combined tarbal.
>
> But this means we will be inflicting some pains on distro's because their
> libv4l packages will go away and be replaced by a new v4l-utils package.

I would call it media-utils. A nice name and it reflects that it contains
both dvb and v4l utilities.

> This is something distro's should be able to handle (it happens more
> often, and I
> know Fedora has procedures for this).
>
> An alternative would be to name the repo and the tarbals libv4l, either is
> fine
> with me (although I'm one of the distro packagers who is going to feel the
> pain
> of a package rename and as such wouldn't mind using libv4l as name for the
> repo and the new tarbals).

We never had a proper release procedure for all the utilities. It's about
time that we start with that and do proper packaging. So I'd rather make a
clean new start now instead of just patching things up.

Just my opinions, of course.

Regards.

      Hans

>
> 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
>


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede]

Hi,

On 02/23/2010 10:01 AM, Hans Verkuil wrote:
>
>> Hi,
>>
>> On 02/22/2010 11:54 PM, Brandon Philips wrote:
>>> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote:
>>>>> lib/
>>>>> 	libv4l1/
>>>>> 	libv4l2/
>>>>> 	libv4lconvert/
>>>>> utils/
>>>>> 	v4l2-dbg
>>>>> 	v4l2-ctl
>>>>> 	cx18-ctl
>>>>> 	ivtv-ctl
>>>>> contrib/
>>>>> 	test/
>>>>> 	everything else
>>>>>
>>>
>>>     git clone git://ifup.org/philips/create-v4l-utils.git
>>>     cd create-v4l-utils/
>>>     ./convert.sh
>>>
>>> You should now have v4l-utils.git which should have this directory
>>> struture. If we need to move other things around let me know and I can
>>> tweak name-filter.sh
>>>
>>
>> Ok, so this will give me a local tree, how do I get this onto linuxtv.org
>> ?
>>
>> Also I need someone to pull:
>> http://linuxtv.org/hg/~hgoede/libv4l
>>
>> (this only contains libv4l commits)
>>
>> Into the:
>> http://linuxtv.org/hg/v4l-dvb
>>
>> Repository, I guess I can ask this directly to Douglas?
>>
>>> Thoughts?
>>
>> I've one question, I think we want to do tarbal releases
>> from this new repo (just like I've been doing with libv4l for a while
>> already), and then want distro's to pick up these releases, right ?
>>
>> Are we going to do separate tarbals for the lib and utils directories,
>> or one combined tarbal. I personally vote for one combined tarbal.
>>
>> But this means we will be inflicting some pains on distro's because their
>> libv4l packages will go away and be replaced by a new v4l-utils package.
>
> I would call it media-utils. A nice name and it reflects that it contains
> both dvb and v4l utilities.
>

Well, the judge is still out on also adding the dvb utils to this git repo.
I'm neutral on that issue, but I will need a co-maintainer for those bits
if they end up in the new v4l-utils repo too.

About the name, if the dvb utils get added and we want to reflect that, lets
call it v4l-dvb-utils. media-utils is not a very descriptive name for v4l-dvb
project outsiders.






>> This is something distro's should be able to handle (it happens more
>> often, and I
>> know Fedora has procedures for this).
>>
>> An alternative would be to name the repo and the tarbals libv4l, either is
>> fine
>> with me (although I'm one of the distro packagers who is going to feel the
>> pain
>> of a package rename and as such wouldn't mind using libv4l as name for the
>> repo and the new tarbals).
>
> We never had a proper release procedure for all the utilities. It's about
> time that we start with that and do proper packaging. So I'd rather make a
> clean new start now instead of just patching things up.
>

Well we need to do some patching up anyways as I would like to align the
versioning of these new tarbals with libv4l versioning, so the first release
/ tarbal will most likely be something-0.8.0.tar.gz

Regards,

Hans

Re: [ANNOUNCE] git tree repositories & libv4l

[Manu Abraham]

On Tue, Feb 23, 2010 at 1:23 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 02/23/2010 10:01 AM, Hans Verkuil wrote:
>>
>>> Hi,
>>>
>>> On 02/22/2010 11:54 PM, Brandon Philips wrote:
>>>>
>>>> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote:
>>>>>>
>>>>>> lib/
>>>>>>        libv4l1/
>>>>>>        libv4l2/
>>>>>>        libv4lconvert/
>>>>>> utils/
>>>>>>        v4l2-dbg
>>>>>>        v4l2-ctl
>>>>>>        cx18-ctl
>>>>>>        ivtv-ctl
>>>>>> contrib/
>>>>>>        test/
>>>>>>        everything else
>>>>>>
>>>>
>>>>    git clone git://ifup.org/philips/create-v4l-utils.git
>>>>    cd create-v4l-utils/
>>>>    ./convert.sh
>>>>
>>>> You should now have v4l-utils.git which should have this directory
>>>> struture. If we need to move other things around let me know and I can
>>>> tweak name-filter.sh
>>>>
>>>
>>> Ok, so this will give me a local tree, how do I get this onto linuxtv.org
>>> ?
>>>
>>> Also I need someone to pull:
>>> http://linuxtv.org/hg/~hgoede/libv4l
>>>
>>> (this only contains libv4l commits)
>>>
>>> Into the:
>>> http://linuxtv.org/hg/v4l-dvb
>>>
>>> Repository, I guess I can ask this directly to Douglas?
>>>
>>>> Thoughts?
>>>
>>> I've one question, I think we want to do tarbal releases
>>> from this new repo (just like I've been doing with libv4l for a while
>>> already), and then want distro's to pick up these releases, right ?
>>>
>>> Are we going to do separate tarbals for the lib and utils directories,
>>> or one combined tarbal. I personally vote for one combined tarbal.
>>>
>>> But this means we will be inflicting some pains on distro's because their
>>> libv4l packages will go away and be replaced by a new v4l-utils package.
>>
>> I would call it media-utils. A nice name and it reflects that it contains
>> both dvb and v4l utilities.
>>
>
> Well, the judge is still out on also adding the dvb utils to this git repo.
> I'm neutral on that issue, but I will need a co-maintainer for those bits
> if they end up in the new v4l-utils repo too.
>
> About the name, if the dvb utils get added and we want to reflect that, lets
> call it v4l-dvb-utils. media-utils is not a very descriptive name for
> v4l-dvb
> project outsiders.


What's the advantage in merging the dvb and v4l2 utils, other than to
make the download/clone bigger ?



Regards,
Manu

Re: [ANNOUNCE] git tree repositories & libv4l

[Manu Abraham]

On Tue, Feb 23, 2010 at 4:41 AM, Mauro Carvalho Chehab
<mchehab@infradead.org> wrote:
> Brandon Philips wrote:
>> On 00:26 Tue 23 Feb 2010, Hans Verkuil wrote:
>>> On Monday 22 February 2010 23:54:26 Brandon Philips wrote:
>>>> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote:
>>>>>> lib/
>>>>>>   libv4l1/
>>>>>>   libv4l2/
>>>>>>   libv4lconvert/
>>>>>> utils/
>>>>>>   v4l2-dbg
>>>>>>   v4l2-ctl
>>>>>>   cx18-ctl
>>>>>>   ivtv-ctl
>>>>>> contrib/
>>>>>>   test/
>>>>>>   everything else
>>>>>>
>>>>   git clone git://ifup.org/philips/create-v4l-utils.git
>>>>   cd create-v4l-utils/
>>>>   ./convert.sh
>>>>
>>>> You should now have v4l-utils.git which should have this directory
>>>> struture. If we need to move other things around let me know and I can
>>>> tweak name-filter.sh
>>>>
>>>> Thoughts? Let me know how we should proceed with dropping v4l2-apps
>>>> from v4l-dvb.
>>>>
>>>> Re: code style cleanup. I think we should do that once we drop
>>>> v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream.
>>> Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was
>>> merged into dvb-apps, but while that tool supports dvb, it also supports
>>> v4l2. Just like we merged dvb and v4l in a single repository, so I think we
>>> should also merge the tools to a media-utils repository.
>>>
>>> It remains a fact of life that dvb and v4l are connected and trying to
>>> artificially keep them apart does not make much sense to me.
>>
>> Easy to do but who should be the maintainer of the dvb things?
>>
>> According to the wiki[1] these tools are without a maintainer. So, if
>> no one cares about them enough to make releases why merge them and
>> clutter up the git tree with dead code?
>>
>> Cheers,
>>
>>       Brandon
>>
>> [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps
>
> That's weird. I've recently added support for ISDB-T on it:
>        http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/


That's probably Michael Krufky (user: Jon2856) from what i guess, he
has been the one who has been making ground for propaganda's on the
wiki.


> and we've got some comments at the mailing list. Btw, the patches
> I added there also adds DVB-S2 support to szap/scan, but tests
> are needed, since I don't have any satellite dish nowadays.


Btw, I did spend time to review your code before it is pulled in. You
did not even provide a reply on my last mail on the subject, or did I
miss that reply of yours ?


Regards,
Manu

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Manu Abraham wrote:

>> and we've got some comments at the mailing list. Btw, the patches
>> I added there also adds DVB-S2 support to szap/scan, but tests
>> are needed, since I don't have any satellite dish nowadays.
> 
> 
> Btw, I did spend time to review your code before it is pulled in. You
> did not even provide a reply on my last mail on the subject, or did I
> miss that reply of yours ?

It is on my todo list. My intention is to work on it after the next
kernel window.


-- 

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Manu Abraham]

On Tue, Feb 23, 2010 at 3:26 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was
> merged into dvb-apps, but while that tool supports dvb, it also supports
> v4l2. Just like we merged dvb and v4l in a single repository, so I think we
> should also merge the tools to a media-utils repository.



Alevt was never maintained. One of the guys who sent a patch wanted a
place to hold his patch and hence it is there.

If you have a better place to put it up, please do let me know. It's
place is not in the dvb-apps tree. It has other dependencies, hence
the build for it is disabled by default.


> It remains a fact of life that dvb and v4l are connected and trying to
> artificially keep them apart does not make much sense to me.


In fact, I don't see anything that's what is common in the digital and
analog applications.

Other than that, I don't see a single line of code from you, in
dvb-apps to make such assertive statements.


Regards,
Manu

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Hans de Goede wrote:
> Hi,
> 
> On 02/22/2010 11:54 PM, Brandon Philips wrote:
>> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote:
>>>> lib/
>>>>     libv4l1/
>>>>     libv4l2/
>>>>     libv4lconvert/
>>>> utils/
>>>>     v4l2-dbg
>>>>     v4l2-ctl
>>>>     cx18-ctl
>>>>     ivtv-ctl
>>>> contrib/
>>>>     test/
>>>>     everything else
>>>>
>>
>>    git clone git://ifup.org/philips/create-v4l-utils.git
>>    cd create-v4l-utils/
>>    ./convert.sh
>>
>> You should now have v4l-utils.git which should have this directory
>> struture. If we need to move other things around let me know and I can
>> tweak name-filter.sh
>>
> 
> Ok, so this will give me a local tree, how do I get this onto linuxtv.org ?

I'll answer first the next question ;)
> 
> Also I need someone to pull:
> http://linuxtv.org/hg/~hgoede/libv4l
> 
> (this only contains libv4l commits)
> 
> Into the:
> http://linuxtv.org/hg/v4l-dvb
> 
> Repository, I guess I can ask this directly to Douglas?

Request it to Douglas. Another option is to merge it locally on your repository,
convert it to git.

After having it converted to git, you should create a repository there for you,
with the -git procedures I've emailed to the ones with accounts there. Then,
ping me and I'll move it to a better place and add permissions for the others
to merge there.
> 
>> Thoughts?
> 
> I've one question, I think we want to do tarbal releases
> from this new repo (just like I've been doing with libv4l for a while
> already), and then want distro's to pick up these releases, right ?
> 
> Are we going to do separate tarbals for the lib and utils directories,
> or one combined tarbal. I personally vote for one combined tarbal.
> 
> But this means we will be inflicting some pains on distro's because their
> libv4l packages will go away and be replaced by a new v4l-utils package.
> This is something distro's should be able to handle (it happens more
> often, and I
> know Fedora has procedures for this).
> 
> An alternative would be to name the repo and the tarbals libv4l, either
> is fine
> with me (although I'm one of the distro packagers who is going to feel
> the pain
> of a package rename and as such wouldn't mind using libv4l as name for the
> repo and the new tarbals).

I think that the better is to create one single tarball. The Makefile may 
have multiple makefile targets for the libraries and for utils. This would 
help distros to create different packages if they want to.

As you're the packager on Fedora, I think you should prepare it to make your
life easier on the distro side. This will probably help other distros too.

-- 

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Hans de Goede wrote:
>> I would call it media-utils. A nice name and it reflects that it contains
>> both dvb and v4l utilities.
>>
> 
> Well, the judge is still out on also adding the dvb utils to this git repo.
> I'm neutral on that issue, but I will need a co-maintainer for those bits
> if they end up in the new v4l-utils repo too.

I also don't have any strong feeling about merging dvb utils. The advantage is
to share the same release control, but the code is completely separated. There
will likely be some developers working on both projects.

A deeper look on what we have on userspace, there are 3 categories of software:
	- apps that handle /dev/v4l/* devices (e. g. V4L2 API hanling);
	- apps that handle /dev/dvb/* devices (e. g. DVB API handling);
	- apps that handle /dev/input/* devices (e. g. IR API handling).

The last one is, in fact just one code, plus lots of IR tables from all V4L and DVB
drivers. The table is created today by the Makefile: it reads the table from the
kernel source tree and generates the tables for the userspace util [*].

If we are maintaining separate trees for each class of device, it might make sense
to have separate a tree for the IR stuff, but this seems overkill to me, since we'll
need to handle 3 separate version controls for each tool class, and, in practice,
v4l/dvb users will need to get more than one tree to get full control of his device.

So, I prefer to have one tree with all 3 types of utilities.

[*] Btw, how Brandon addressed it with the conversion tool? I think we'll need to add
some tools there to handle the kernel driver <-> v4l2-apps interdependency, e. g.
creating the *.c.xml files needed by the media-specs and importing the IR keymaps from
the driver sources.

-- 

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Manu Abraham wrote:
> On Tue, Feb 23, 2010 at 1:23 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 02/23/2010 10:01 AM, Hans Verkuil wrote:
>>>> Hi,
>>>>
>>>> On 02/22/2010 11:54 PM, Brandon Philips wrote:
>>>>> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote:
>>>>>>> lib/
>>>>>>>        libv4l1/
>>>>>>>        libv4l2/
>>>>>>>        libv4lconvert/
>>>>>>> utils/
>>>>>>>        v4l2-dbg
>>>>>>>        v4l2-ctl
>>>>>>>        cx18-ctl
>>>>>>>        ivtv-ctl
>>>>>>> contrib/
>>>>>>>        test/
>>>>>>>        everything else
>>>>>>>
>>>>>    git clone git://ifup.org/philips/create-v4l-utils.git
>>>>>    cd create-v4l-utils/
>>>>>    ./convert.sh
>>>>>
>>>>> You should now have v4l-utils.git which should have this directory
>>>>> struture. If we need to move other things around let me know and I can
>>>>> tweak name-filter.sh
>>>>>
>>>> Ok, so this will give me a local tree, how do I get this onto linuxtv.org
>>>> ?
>>>>
>>>> Also I need someone to pull:
>>>> http://linuxtv.org/hg/~hgoede/libv4l
>>>>
>>>> (this only contains libv4l commits)
>>>>
>>>> Into the:
>>>> http://linuxtv.org/hg/v4l-dvb
>>>>
>>>> Repository, I guess I can ask this directly to Douglas?
>>>>
>>>>> Thoughts?
>>>> I've one question, I think we want to do tarbal releases
>>>> from this new repo (just like I've been doing with libv4l for a while
>>>> already), and then want distro's to pick up these releases, right ?
>>>>
>>>> Are we going to do separate tarbals for the lib and utils directories,
>>>> or one combined tarbal. I personally vote for one combined tarbal.
>>>>
>>>> But this means we will be inflicting some pains on distro's because their
>>>> libv4l packages will go away and be replaced by a new v4l-utils package.
>>> I would call it media-utils. A nice name and it reflects that it contains
>>> both dvb and v4l utilities.
>>>
>> Well, the judge is still out on also adding the dvb utils to this git repo.
>> I'm neutral on that issue, but I will need a co-maintainer for those bits
>> if they end up in the new v4l-utils repo too.
>>
>> About the name, if the dvb utils get added and we want to reflect that, lets
>> call it v4l-dvb-utils. media-utils is not a very descriptive name for
>> v4l-dvb
>> project outsiders.
> 
> 
> What's the advantage in merging the dvb and v4l2 utils, other than to
> make the download/clone bigger ?

There aren't any big advantages on merging, nor there are big advantages on keeping
them alone.

Advantages to merge:
	- One single release control. Currently, only Hans de Goede is doing a
good job with release names, on libv4l. By having everything into one place, all other
v4l2-apps and dvb-apps will have a release name, making easier even for us when helping
people with troubles (as we'll know for sure if they're using the latest version or
a very old version;
	- One single tree for the user to download, for IR, DVB and V4L apps;
	- Distro packagers will have one single tarball to maintain.

Disadvantages:
	- More people will need access to the same git master tree;
	- The tree will be bigger.


-- 

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Manu Abraham]

On Tue, Feb 23, 2010 at 4:21 PM, Mauro Carvalho Chehab
<mchehab@infradead.org> wrote:
> Manu Abraham wrote:
>> On Tue, Feb 23, 2010 at 1:23 PM, Hans de Goede <hdegoede@redhat.com> wrote:

[snip]

>>
>>
>> What's the advantage in merging the dvb and v4l2 utils, other than to
>> make the download/clone bigger ?
>
> There aren't any big advantages on merging, nor there are big advantages on keeping
> them alone.
>
> Advantages to merge:
>        - One single release control. Currently, only Hans de Goede is doing a
> good job with release names, on libv4l. By having everything into one place, all other
> v4l2-apps and dvb-apps will have a release name, making easier even for us when helping
> people with troubles (as we'll know for sure if they're using the latest version or
> a very old version;
>        - One single tree for the user to download, for IR, DVB and V4L apps;
>        - Distro packagers will have one single tarball to maintain.
>
> Disadvantages:
>        - More people will need access to the same git master tree;
>        - The tree will be bigger.


It is quite noble to think of having to have everything unified in the
world. But that doesn't seem how things are in practice. It's quite
understood that the concept of "one-single-ring-to-rule-them-all"
doesn't work well.

The mercurial dvb-apps tree has worked quite well for me as well as
the other few people who have been involved with it and don't have any
problems in that arena and I am very happy with it on that front.

FWIW, I am not very much interested to move to git.

Are we making a mockery, switching between SCM's every now and then .. ?

Maybe there are others as well, who feel that way. But that's not the
more important point. For me, it is like simply that a simple update
is quite fast and easy.

FWIW: dvb-apps is not about any real application development, but acts
as an aid for other applications to be built. In some cases, it can
aid as a quick test tools, which can isolate users issues, when carry
forward issues from other applications.

On the contrary we have had a few libs, which are in use by some
applications. These came up as Andrew, myself and Julian wanted to
have some libraries to setup things real quick. Johannes provided some
directions in which how developments could proceed to make things look
good. Later on, Andrew ran away from all v4l, dvb related
developments, because he was irritated quite a lot too much.


With regards to distro stuff; This is best left to distro vendors. I
don't really appreciate this distro-speak that you make every now and
then. In the light that which you speak, it would be even much nobler
to think of a pakage or rpm such as
distro-application-packages.foobar. But such a merging of all the
applications and utilities do not really mean anything and is useless.
All it does is: irritate people.


With regards to release control, we have had a 1.1.1 release. Looking
back, we haven't had a proper stable state yet, for another release.
Thinking of which, it is more of these discussions that hold back real
development rather than anything else. Moving to git, or have a merged
tree with v4l2 and dvb utils is not going to make dvb-apps development
any faster.

On the contrary, I don't think it is going to help dvb-apps in anyway
on the development front, but rather make it worser.


My few cents, being one of the dvb-apps maintainers and author of some
the bits and pieces in it.

Regards,
Manu

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Manu Abraham wrote:
>>> What's the advantage in merging the dvb and v4l2 utils, other than to
>>> make the download/clone bigger ?
>> There aren't any big advantages on merging, nor there are big advantages on keeping
>> them alone.
>>
>> Advantages to merge:
>>        - One single release control. Currently, only Hans de Goede is doing a
>> good job with release names, on libv4l. By having everything into one place, all other
>> v4l2-apps and dvb-apps will have a release name, making easier even for us when helping
>> people with troubles (as we'll know for sure if they're using the latest version or
>> a very old version;
>>        - One single tree for the user to download, for IR, DVB and V4L apps;
>>        - Distro packagers will have one single tarball to maintain.
>>
>> Disadvantages:
>>        - More people will need access to the same git master tree;
>>        - The tree will be bigger.
> 
> 
> It is quite noble to think of having to have everything unified in the
> world. But that doesn't seem how things are in practice. It's quite
> understood that the concept of "one-single-ring-to-rule-them-all"
> doesn't work well.
> 
> The mercurial dvb-apps tree has worked quite well for me as well as
> the other few people who have been involved with it and don't have any
> problems in that arena and I am very happy with it on that front.
> 
> FWIW, I am not very much interested to move to git.
> 
> Are we making a mockery, switching between SCM's every now and then .. ?
> 
> Maybe there are others as well, who feel that way. But that's not the
> more important point. For me, it is like simply that a simple update
> is quite fast and easy.

I don't think moving it to git would bring any significant advantage or 
disadvantage.

> With regards to distro stuff; This is best left to distro vendors.

Agreed.

> With regards to release control, we have had a 1.1.1 release. Looking
> back, we haven't had a proper stable state yet, for another release.

Hmm...
	http://www.linuxtv.org/downloads/

May, 18 2006... 

$ hg log -d ">05/18/2006" -p|diffstat -p1|grep changed
 1402 files changed, 66559 insertions(+), 16267 deletions(-)

Sorry, but it is really failing with release control. There were _lots_ of change
since 2006, including several new applications, and tons of new channel/transponders
added to it.

> Thinking of which, it is more of these discussions that hold back real
> development rather than anything else. Moving to git, or have a merged
> tree with v4l2 and dvb utils is not going to make dvb-apps development
> any faster.
> 
> On the contrary, I don't think it is going to help dvb-apps in anyway
> on the development front, but rather make it worser.

Why would it be worse?

> My few cents, being one of the dvb-apps maintainers and author of some
> the bits and pieces in it.

PS.: while removing that "need maintainer" warning from the wiki, I noticed that,
just like v4l2-apps, there's one application there for IR (util/av7110_loadkeys).

Even if we decide to keep the trees separate, we should really put this utility 
and the IR code at v4l2-apps at the same place.

-- 

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Brandon Philips wrote:
> On 22:12 Mon 22 Feb 2010, Mauro Carvalho Chehab wrote:
>> Mauro Carvalho Chehab wrote:

>> That's said, if all the issues are the ones listed above, I can try
>> to address them on the next months, to put it into a better
>> shape. That's said, I don't think we should have a single maintainer
>> for it: there are too many DTV standards already, and probably
>> nobody with enough time has access to all of those (DVB-T, DVB-T2,
>> DVB-S, DVB-S2, ISDB-T, ISDB-S, ATSC, DSS, ...).  So, I think we need
>> a team of volunteers that will try to help with the standards they
>> have access.
> 
> I was not suggesting a single maintainer but I wanted to make sure
> there was actual interest in maintaing and fixing these dvb things. I
> don't interact much at all with DVB so all I had to go on was the wiki
> page.

The wiki seems wrong to me. I'll update it.

-- 

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Manu Abraham]

On Tue, Feb 23, 2010 at 5:36 PM, Mauro Carvalho Chehab
<mchehab@infradead.org> wrote:
> Manu Abraham wrote:
>>>> What's the advantage in merging the dvb and v4l2 utils, other than to
>>>> make the download/clone bigger ?
>>> There aren't any big advantages on merging, nor there are big advantages on keeping
>>> them alone.
>>>
>>> Advantages to merge:
>>>        - One single release control. Currently, only Hans de Goede is doing a
>>> good job with release names, on libv4l. By having everything into one place, all other
>>> v4l2-apps and dvb-apps will have a release name, making easier even for us when helping
>>> people with troubles (as we'll know for sure if they're using the latest version or
>>> a very old version;
>>>        - One single tree for the user to download, for IR, DVB and V4L apps;
>>>        - Distro packagers will have one single tarball to maintain.
>>>
>>> Disadvantages:
>>>        - More people will need access to the same git master tree;
>>>        - The tree will be bigger.
>>
>>
>> It is quite noble to think of having to have everything unified in the
>> world. But that doesn't seem how things are in practice. It's quite
>> understood that the concept of "one-single-ring-to-rule-them-all"
>> doesn't work well.
>>
>> The mercurial dvb-apps tree has worked quite well for me as well as
>> the other few people who have been involved with it and don't have any
>> problems in that arena and I am very happy with it on that front.
>>
>> FWIW, I am not very much interested to move to git.
>>
>> Are we making a mockery, switching between SCM's every now and then .. ?
>>
>> Maybe there are others as well, who feel that way. But that's not the
>> more important point. For me, it is like simply that a simple update
>> is quite fast and easy.
>
> I don't think moving it to git would bring any significant advantage or
> disadvantage.
>
>> With regards to distro stuff; This is best left to distro vendors.
>
> Agreed.
>
>> With regards to release control, we have had a 1.1.1 release. Looking
>> back, we haven't had a proper stable state yet, for another release.
>
> Hmm...
>        http://www.linuxtv.org/downloads/
>
> May, 18 2006...
>
> $ hg log -d ">05/18/2006" -p|diffstat -p1|grep changed
>  1402 files changed, 66559 insertions(+), 16267 deletions(-)
>
> Sorry, but it is really failing with release control. There were _lots_ of change
> since 2006, including several new applications, and tons of new channel/transponders
> added to it.



I don't simply see how adding in a version number is going to help in
moving things ahead. Anyone wishing to download the latest tip can
dowload from
http://linuxtv.org/hg/dvb-apps/archive/tip.tar.bz2

if one is not content with cloning the whole tree.




>> Thinking of which, it is more of these discussions that hold back real
>> development rather than anything else. Moving to git, or have a merged
>> tree with v4l2 and dvb utils is not going to make dvb-apps development
>> any faster.
>>
>> On the contrary, I don't think it is going to help dvb-apps in anyway
>> on the development front, but rather make it worser.
>
> Why would it be worse?


Anything that which doesn't make things better, but that brings in an
overhead, is something worser.

- I would need to get going on with git

- It's going to be the 3rd time there is a SCM change. Changing it all
the time doesn't help the users nor the people who work on it.

- The additional overhead to download larger content, however small
that might be initially to start up with.

- mixing up things that which are not really tied to each other


>> My few cents, being one of the dvb-apps maintainers and author of some
>> the bits and pieces in it.
>
> PS.: while removing that "need maintainer" warning from the wiki, I noticed that,
> just like v4l2-apps, there's one application there for IR (util/av7110_loadkeys).
>
> Even if we decide to keep the trees separate, we should really put this utility
> and the IR code at v4l2-apps at the same place.


It has been there for ages, originally Holger had it there, during the
time of convergence.  FF card users have been using it since. Probably
FF users would like to mention what they would like to have and
comment on that.


Regards,
Manu

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Hans de Goede wrote:

> Ok, so this will give me a local tree, how do I get this onto linuxtv.org ?

I added it. In thesis, it is open for commit to you, me, hverkuil and dougsland.

The tree is small: just 860Kb, after properly packed.

Brandon, I need an ssh public key from you to enable your access. Please send it to me
in priv.

Did I miss anybody?

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede]

Hi,

On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
> Hans de Goede wrote:
>
>> Ok, so this will give me a local tree, how do I get this onto linuxtv.org ?
>
> I added it. In thesis, it is open for commit to you, me, hverkuil and dougsland.
>

I see good, thanks! Can someone (Douglas ?) with better hg / git powers then me please
somehow import all the libv4l changes from:
http://linuxtv.org/hg/~hgoede/libv4l

Once that is done I'll retire my own tree, and move all my userspace work to
the git tree.

For starters I plan to create / modify Makefiles so that everything will build
out of the box, and has proper make install targets which can be used by distro's

So:
-proper honoring of CFLAGS
-work with standard (and possibly somewhat older kernel headers)
-honor DESTDIR, PREFIX and LIBDIR when doing make install

When I'm satisfied (and have created some proof of concept packages for
Fedora to make sure everything is reasonably usable for distros). I'll
send a mail to the list announcing my intend to release a 0.8.0 version
(building on top of existing libv4l release scheme to make clear
  which libv4l version is included). If there are then no objections /
bugs found I'll do a 0.8.0 release .

Regards,

Hans

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Hans de Goede wrote:
> Hi,
> 
> On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
>> Hans de Goede wrote:
>>
>>> Ok, so this will give me a local tree, how do I get this onto
>>> linuxtv.org ?
>>
>> I added it. In thesis, it is open for commit to you, me, hverkuil and
>> dougsland.
>>
> 
> I see good, thanks! Can someone (Douglas ?) with better hg / git powers
> then me please
> somehow import all the libv4l changes from:
> http://linuxtv.org/hg/~hgoede/libv4l

Ok, I added there. The procedure were simple: I ran Brandon script again,
but after pulling from your tree. Then, I used git format-patch to generate
a quilt series, and used git quiltimport on the correct -git tree.

> Once that is done I'll retire my own tree, and move all my userspace
> work to
> the git tree.
> 
> For starters I plan to create / modify Makefiles so that everything will
> build
> out of the box, and has proper make install targets which can be used by
> distro's
> 
> So:
> -proper honoring of CFLAGS
> -work with standard (and possibly somewhat older kernel headers)
> -honor DESTDIR, PREFIX and LIBDIR when doing make install

The better here is to have the latest kernel headers copied on the tree.
This way, it is possible to compile libv4l2 with an older kernel version and
later upgrade the kernel, if needed, or to use a fast machine to compile
it, and then use it on another machine.

-- 

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[hermann pitton]

Am Dienstag, den 23.02.2010, 13:45 +0400 schrieb Manu Abraham:
> On Tue, Feb 23, 2010 at 4:41 AM, Mauro Carvalho Chehab
> <mchehab@infradead.org> wrote:
> > Brandon Philips wrote:
> >> On 00:26 Tue 23 Feb 2010, Hans Verkuil wrote:
> >>> On Monday 22 February 2010 23:54:26 Brandon Philips wrote:
> >>>> On 18:24 Sat 23 Jan 2010, Hans de Goede wrote:
> >>>>>> lib/
> >>>>>>   libv4l1/
> >>>>>>   libv4l2/
> >>>>>>   libv4lconvert/
> >>>>>> utils/
> >>>>>>   v4l2-dbg
> >>>>>>   v4l2-ctl
> >>>>>>   cx18-ctl
> >>>>>>   ivtv-ctl
> >>>>>> contrib/
> >>>>>>   test/
> >>>>>>   everything else
> >>>>>>
> >>>>   git clone git://ifup.org/philips/create-v4l-utils.git
> >>>>   cd create-v4l-utils/
> >>>>   ./convert.sh
> >>>>
> >>>> You should now have v4l-utils.git which should have this directory
> >>>> struture. If we need to move other things around let me know and I can
> >>>> tweak name-filter.sh
> >>>>
> >>>> Thoughts? Let me know how we should proceed with dropping v4l2-apps
> >>>> from v4l-dvb.
> >>>>
> >>>> Re: code style cleanup. I think we should do that once we drop
> >>>> v4l2-apps/ from v4l-dvb and make the new v4l-utils.git upstream.
> >>> Question: shouldn't we merge dvb-apps and v4l-utils? The alevtv tool was
> >>> merged into dvb-apps, but while that tool supports dvb, it also supports
> >>> v4l2. Just like we merged dvb and v4l in a single repository, so I think we
> >>> should also merge the tools to a media-utils repository.
> >>>
> >>> It remains a fact of life that dvb and v4l are connected and trying to
> >>> artificially keep them apart does not make much sense to me.
> >>
> >> Easy to do but who should be the maintainer of the dvb things?
> >>
> >> According to the wiki[1] these tools are without a maintainer. So, if
> >> no one cares about them enough to make releases why merge them and
> >> clutter up the git tree with dead code?
> >>
> >> Cheers,
> >>
> >>       Brandon
> >>
> >> [1] http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps
> >
> > That's weird. I've recently added support for ISDB-T on it:
> >        http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt2/
> 
> 
> That's probably Michael Krufky (user: Jon2856) from what i guess, he
> has been the one who has been making ground for propaganda's on the
> wiki.

Manu, you are actively calling the trolls back again with such
accusations!

It is the other way round, you own him at least one clear excuse.

Cheers,
Hermann

> > and we've got some comments at the mailing list. Btw, the patches
> > I added there also adds DVB-S2 support to szap/scan, but tests
> > are needed, since I don't have any satellite dish nowadays.
> 
> 
> Btw, I did spend time to review your code before it is pulled in. You
> did not even provide a reply on my last mail on the subject, or did I
> miss that reply of yours ?
> 
> 
> Regards,
> Manu

Re: [ANNOUNCE] git tree repositories & libv4l

[Brandon Philips]

On 16:51 Tue 23 Feb 2010, Hans de Goede wrote:
> On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
> >Hans de Goede wrote:
> >
> >>Ok, so this will give me a local tree, how do I get this onto
> >>linuxtv.org ?
> >
> >I added it. In thesis, it is open for commit to you, me, hverkuil
> >and dougsland.
> >
> 
> I see good, thanks! Can someone (Douglas ?) with better hg / git
> powers then me please somehow import all the libv4l changes from:
> http://linuxtv.org/hg/~hgoede/libv4l
> 
> Once that is done I'll retire my own tree, and move all my userspace
> work to the git tree.
> 
> For starters I plan to create / modify Makefiles so that everything
> will build out of the box, and has proper make install targets which
> can be used by distro's
> 
> So:
> -proper honoring of CFLAGS
> -work with standard (and possibly somewhat older kernel headers)
> -honor DESTDIR, PREFIX and LIBDIR when doing make install

Do you still want me to convert to autoconf? I was still planning on
doing that. We discussed it a month ago when this conversation
started.

http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15009

> When I'm satisfied (and have created some proof of concept packages
> for Fedora to make sure everything is reasonably usable for
> distros). I'll send a mail to the list announcing my intend to
> release a 0.8.0 version (building on top of existing libv4l release
> scheme to make clear which libv4l version is included). If there are
> then no objections / bugs found I'll do a 0.8.0 release .

Ack, sounds good. 

Thanks,

	Brandon

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede]

Hi,

On 02/24/2010 07:05 AM, Brandon Philips wrote:
> On 16:51 Tue 23 Feb 2010, Hans de Goede wrote:
>> On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
>>> Hans de Goede wrote:
>>>
>>>> Ok, so this will give me a local tree, how do I get this onto
>>>> linuxtv.org ?
>>>
>>> I added it. In thesis, it is open for commit to you, me, hverkuil
>>> and dougsland.
>>>
>>
>> I see good, thanks! Can someone (Douglas ?) with better hg / git
>> powers then me please somehow import all the libv4l changes from:
>> http://linuxtv.org/hg/~hgoede/libv4l
>>
>> Once that is done I'll retire my own tree, and move all my userspace
>> work to the git tree.
>>
>> For starters I plan to create / modify Makefiles so that everything
>> will build out of the box, and has proper make install targets which
>> can be used by distro's
>>
>> So:
>> -proper honoring of CFLAGS
>> -work with standard (and possibly somewhat older kernel headers)
>> -honor DESTDIR, PREFIX and LIBDIR when doing make install
>
> Do you still want me to convert to autoconf? I was still planning on
> doing that. We discussed it a month ago when this conversation
> started.
>
> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15009
>

I know that was mentioned then, but re-thinking this, as this will all
be Linux specific, I don't really see a need for autotools atm, and as
I personally find autotools a bit overcomplicated. I would like to try
just using plain Makefiles for now. If it turns out this does not work
we can always switch to autotools later.

Thanks for the offer though!

Regards,

Hans

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede]

Hi,

On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:
> Hans de Goede wrote:
>> Hi,
>>
>> On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
>>> Hans de Goede wrote:
>>>
>>>> Ok, so this will give me a local tree, how do I get this onto
>>>> linuxtv.org ?
>>>
>>> I added it. In thesis, it is open for commit to you, me, hverkuil and
>>> dougsland.
>>>
>>
>> I see good, thanks! Can someone (Douglas ?) with better hg / git powers
>> then me please
>> somehow import all the libv4l changes from:
>> http://linuxtv.org/hg/~hgoede/libv4l
>
> Ok, I added there. The procedure were simple: I ran Brandon script again,
> but after pulling from your tree. Then, I used git format-patch to generate
> a quilt series, and used git quiltimport on the correct -git tree.
>

Thanks!


>> Once that is done I'll retire my own tree, and move all my userspace
>> work to
>> the git tree.
>>
>> For starters I plan to create / modify Makefiles so that everything will
>> build
>> out of the box, and has proper make install targets which can be used by
>> distro's
>>
>> So:
>> -proper honoring of CFLAGS
>> -work with standard (and possibly somewhat older kernel headers)
>> -honor DESTDIR, PREFIX and LIBDIR when doing make install
>
> The better here is to have the latest kernel headers copied on the tree.
> This way, it is possible to compile libv4l2 with an older kernel version and
> later upgrade the kernel, if needed, or to use a fast machine to compile
> it, and then use it on another machine.
>

If possible I would like to avoid this, afaik no other userspace utility packages
are doing this.

Where necessary libv4l currently has code snippets like:

#ifndef V4L2_PIX_FMT_SPCA501
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
#endif

So libv4l (in its current state) will already compile fine with older kernel
headers. I expect that the other utilities will not need a lot of
recent kernel ABI. So for now I would like to try and extend the above approach
to the other utilities.

The reason for this is that I want to avoid carrying a copy of a dir from some
other tree, with all getting stale and needing sync all the time issues that
come with that, not to mention chicken and egg problems in the case of
new formats which simultaneously  need to be added to both libv4l and the kernel.

For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l, before it
hits any official v4l-dvb kernel tree, with the:
#ifndef V4L2_PIX_FMT_SPCA501
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
#endif

Approach this works fine, if I were to carry an include tree copy, that would
now need to become a patched include tree copy, and with the next sync I then
need to ensure that any needed patches are either already in the sync source,
or applied again.

Regards,

Hans

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Hans de Goede wrote:
> Hi,
> 
> On 02/24/2010 07:05 AM, Brandon Philips wrote:
>> On 16:51 Tue 23 Feb 2010, Hans de Goede wrote:
>>> On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
>>>> Hans de Goede wrote:
>>>>
>>>>> Ok, so this will give me a local tree, how do I get this onto
>>>>> linuxtv.org ?
>>>>
>>>> I added it. In thesis, it is open for commit to you, me, hverkuil
>>>> and dougsland.
>>>>
>>>
>>> I see good, thanks! Can someone (Douglas ?) with better hg / git
>>> powers then me please somehow import all the libv4l changes from:
>>> http://linuxtv.org/hg/~hgoede/libv4l
>>>
>>> Once that is done I'll retire my own tree, and move all my userspace
>>> work to the git tree.
>>>
>>> For starters I plan to create / modify Makefiles so that everything
>>> will build out of the box, and has proper make install targets which
>>> can be used by distro's
>>>
>>> So:
>>> -proper honoring of CFLAGS
>>> -work with standard (and possibly somewhat older kernel headers)
>>> -honor DESTDIR, PREFIX and LIBDIR when doing make install
>>
>> Do you still want me to convert to autoconf? I was still planning on
>> doing that. We discussed it a month ago when this conversation
>> started.
>>
>> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15009
>>
>>
> 
> I know that was mentioned then, but re-thinking this, as this will all
> be Linux specific, I don't really see a need for autotools atm, and as
> I personally find autotools a bit overcomplicated. I would like to try
> just using plain Makefiles for now. If it turns out this does not work
> we can always switch to autotools later.

I suspect it won't work fine. There are some library dependencies at 
utils/contrib, like libsysfs and libqt stuff. The build system should or
refuse to compile or disable some of those tools if the dependencies are
missing.

Of course you may create a non-autotools configure script that checks for
those libraries. They aren't many, so this approach works, but it will
likely require more time than using autotools.


Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans Verkuil]

> Hi,
>
> On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:
>> Hans de Goede wrote:
>>> Hi,
>>>
>>> On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
>>>> Hans de Goede wrote:
>>>>
>>>>> Ok, so this will give me a local tree, how do I get this onto
>>>>> linuxtv.org ?
>>>>
>>>> I added it. In thesis, it is open for commit to you, me, hverkuil and
>>>> dougsland.
>>>>
>>>
>>> I see good, thanks! Can someone (Douglas ?) with better hg / git powers
>>> then me please
>>> somehow import all the libv4l changes from:
>>> http://linuxtv.org/hg/~hgoede/libv4l
>>
>> Ok, I added there. The procedure were simple: I ran Brandon script
>> again,
>> but after pulling from your tree. Then, I used git format-patch to
>> generate
>> a quilt series, and used git quiltimport on the correct -git tree.
>>
>
> Thanks!
>
>
>>> Once that is done I'll retire my own tree, and move all my userspace
>>> work to
>>> the git tree.
>>>
>>> For starters I plan to create / modify Makefiles so that everything
>>> will
>>> build
>>> out of the box, and has proper make install targets which can be used
>>> by
>>> distro's
>>>
>>> So:
>>> -proper honoring of CFLAGS
>>> -work with standard (and possibly somewhat older kernel headers)
>>> -honor DESTDIR, PREFIX and LIBDIR when doing make install
>>
>> The better here is to have the latest kernel headers copied on the tree.
>> This way, it is possible to compile libv4l2 with an older kernel version
>> and
>> later upgrade the kernel, if needed, or to use a fast machine to compile
>> it, and then use it on another machine.
>>
>
> If possible I would like to avoid this, afaik no other userspace utility
> packages
> are doing this.
>
> Where necessary libv4l currently has code snippets like:
>
> #ifndef V4L2_PIX_FMT_SPCA501
> #define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line
> */
> #endif
>
> So libv4l (in its current state) will already compile fine with older
> kernel
> headers. I expect that the other utilities will not need a lot of
> recent kernel ABI. So for now I would like to try and extend the above
> approach
> to the other utilities.

Note that the v4l2-ctl and v4l2-dbg utilities often *do* track the latest
kernel. In particular v4l2-ctl is often used to control/test new features.

Regards,

         Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

Re: [ANNOUNCE] git tree repositories & libv4l

[Mauro Carvalho Chehab]

Hans de Goede wrote:
> Hi,
> 
> On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:
>> Hans de Goede wrote:
>>> Hi,
>>>
>>> On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
>>>> Hans de Goede wrote:
>>>>
>>>>> Ok, so this will give me a local tree, how do I get this onto
>>>>> linuxtv.org ?
>>>>
>>>> I added it. In thesis, it is open for commit to you, me, hverkuil and
>>>> dougsland.
>>>>
>>>
>>> I see good, thanks! Can someone (Douglas ?) with better hg / git powers
>>> then me please
>>> somehow import all the libv4l changes from:
>>> http://linuxtv.org/hg/~hgoede/libv4l
>>
>> Ok, I added there. The procedure were simple: I ran Brandon script again,
>> but after pulling from your tree. Then, I used git format-patch to
>> generate
>> a quilt series, and used git quiltimport on the correct -git tree.
>>
> 
> Thanks!
> 
> 
>>> Once that is done I'll retire my own tree, and move all my userspace
>>> work to
>>> the git tree.
>>>
>>> For starters I plan to create / modify Makefiles so that everything will
>>> build
>>> out of the box, and has proper make install targets which can be used by
>>> distro's
>>>
>>> So:
>>> -proper honoring of CFLAGS
>>> -work with standard (and possibly somewhat older kernel headers)
>>> -honor DESTDIR, PREFIX and LIBDIR when doing make install
>>
>> The better here is to have the latest kernel headers copied on the tree.
>> This way, it is possible to compile libv4l2 with an older kernel
>> version and
>> later upgrade the kernel, if needed, or to use a fast machine to compile
>> it, and then use it on another machine.
>>
> 
> If possible I would like to avoid this, afaik no other userspace utility
> packages
> are doing this.
> 
> Where necessary libv4l currently has code snippets like:
> 
> #ifndef V4L2_PIX_FMT_SPCA501
> #define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per
> line */
> #endif
> 
> So libv4l (in its current state) will already compile fine with older
> kernel
> headers. I expect that the other utilities will not need a lot of
> recent kernel ABI. So for now I would like to try and extend the above
> approach
> to the other utilities.

I think build will fail. I remember I had some such troubles when compiling
it against RHEL5, before we did the merge with the in-tree videodev2.h.

It should be reminded that, when people upgrade their kernels by hand,
they generally don't run "make headers_install". So, the kernel headers
on /usr/include/linux are the ones found on the original distro kernel,
and not the ones that are needed by the user.

> The reason for this is that I want to avoid carrying a copy of a dir
> from some
> other tree, with all getting stale and needing sync all the time issues
> that
> come with that,

The sync problem will keep existing, since some of the tools from
this tree are used as examples on media-specs.

> not to mention chicken and egg problems in the case of
> new formats which simultaneously  need to be added to both libv4l and
> the kernel.
> 
> For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l,
> before it
> hits any official v4l-dvb kernel tree, with the:
> #ifndef V4L2_PIX_FMT_SPCA501
> #define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per
> line */
> #endif
> 
> Approach this works fine, if I were to carry an include tree copy, that
> would
> now need to become a patched include tree copy, and with the next sync I
> then
> need to ensure that any needed patches are either already in the sync
> source,
> or applied again.

True, but the additional work for those occasional changes are minimum, and
may save some time when handling complains about why the tree don't build
on his machine.

-- 

Cheers,
Mauro

Re: [ANNOUNCE] git tree repositories & libv4l

[Patrick Boettcher]

Hi all,

On Wed, 24 Feb 2010, Mauro Carvalho Chehab wrote:
>> I know that was mentioned then, but re-thinking this, as this will all
>> be Linux specific, I don't really see a need for autotools atm, and as
>> I personally find autotools a bit overcomplicated. I would like to try
>> just using plain Makefiles for now. If it turns out this does not work
>> we can always switch to autotools later.
>
> I suspect it won't work fine. There are some library dependencies at
> utils/contrib, like libsysfs and libqt stuff. The build system should or
> refuse to compile or disable some of those tools if the dependencies are
> missing.

Have a look at cmake: cmake.org . It is extremely powerful in terms of 
external-library--detection, it can do QT natively and all other things 
around library generation and dependencies.

Cmake has become my favorite build-tool for user-space development.

Just my 2cts.

--

Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/

Re: [ANNOUNCE] git tree repositories & libv4l

[Brandon Philips]

On 13:55 Wed 24 Feb 2010, Hans de Goede wrote:
> On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:
> >Hans de Goede wrote:
> >The better here is to have the latest kernel headers copied on the tree.
> >This way, it is possible to compile libv4l2 with an older kernel version and
> >later upgrade the kernel, if needed, or to use a fast machine to compile
> >it, and then use it on another machine.
> >
> 
> If possible I would like to avoid this, afaik no other userspace
> utility packages are doing this.

Off the top of my head I know ethtool does this. It greatly simplifies
the work of maintaing the package:

  http://git.kernel.org/?p=network/ethtool/ethtool.git;a=blob;f=ethtool-copy.h;h=09dd5480ff3488214ab67ad04459541314291f79;hb=HEAD

> Where necessary libv4l currently has code snippets like:
> 
> #ifndef V4L2_PIX_FMT_SPCA501
> #define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
> #endif

I don't think this is less work than copying the header file from the
Kernel. Test building under all versions of the Kernel headers that
exist to make sure something isn't missed isn't possible. It really is
easier just to sync the header file up.

> The reason for this is that I want to avoid carrying a copy of a dir
> from some other tree, with all getting stale and needing sync all
> the time issues that come with that, not to mention chicken and egg
> problems in the case of new formats which simultaneously need to be
> added to both libv4l and the kernel.

Worst case is that if it is stale then it won't build since it depends
on fancy new feature XYZ. But, at least it won't build on all systems
instead of randomly breaking based on installed kernel headers
version.

> For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l, before it
> hits any official v4l-dvb kernel tree, with the:

Please don't add features to releases before they are merged with
Linus. It would suck to ship a copy of libv4l that has a different
idea of structs or constants then the upstream Kernel.

> Approach this works fine, if I were to carry an include tree copy, that would
> now need to become a patched include tree copy, and with the next sync I then
> need to ensure that any needed patches are either already in the sync source,
> or applied again.

Or just fix it upstream with #ifdef __KERNEL__ tags once and for all,
right?

Cheers,

	Brandon

Re: [ANNOUNCE] git tree repositories & libv4l

[Douglas Schilling Landgraf]

Hello all,

On 02/23/2010 10:51 AM, Hans de Goede wrote:
> Hi,
>
> On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
>> Hans de Goede wrote:
>>
>>> Ok, so this will give me a local tree, how do I get this onto 
>>> linuxtv.org ?
>>
>> I added it. In thesis, it is open for commit to you, me, hverkuil and 
>> dougsland.
>>
>
> I see good, thanks! Can someone (Douglas ?) with better hg / git 
> powers then me please
> somehow import all the libv4l changes from:
> http://linuxtv.org/hg/~hgoede/libv4l
>
Done!

Cheers
Douglas

Re: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede]

Hi,

On 02/24/2010 03:32 PM, Brandon Philips wrote:
> On 13:55 Wed 24 Feb 2010, Hans de Goede wrote:

<snip>
>> Where necessary libv4l currently has code snippets like:
>>
>> #ifndef V4L2_PIX_FMT_SPCA501
>> #define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
>> #endif
>
> I don't think this is less work than copying the header file from the
> Kernel. Test building under all versions of the Kernel headers that
> exist to make sure something isn't missed isn't possible. It really is
> easier just to sync the header file up.
>
>> The reason for this is that I want to avoid carrying a copy of a dir
>> from some other tree, with all getting stale and needing sync all
>> the time issues that come with that, not to mention chicken and egg
>> problems in the case of new formats which simultaneously need to be
>> added to both libv4l and the kernel.
>
> Worst case is that if it is stale then it won't build since it depends
> on fancy new feature XYZ. But, at least it won't build on all systems
> instead of randomly breaking based on installed kernel headers
> version.
>
>> For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l, before it
>> hits any official v4l-dvb kernel tree, with the:
>
> Please don't add features to releases before they are merged with
> Linus. It would suck to ship a copy of libv4l that has a different
> idea of structs or constants then the upstream Kernel.
>

Note the only thing added is a V4L2_PIX_FMT_xxx define, IOW this makes libv4l
recognize (and convert from) a new video format, which is to be generated
by a going upstream soon driver. With older kernels this won't make any
difference as those don't generate that format.

>> Approach this works fine, if I were to carry an include tree copy, that would
>> now need to become a patched include tree copy, and with the next sync I then
>> need to ensure that any needed patches are either already in the sync source,
>> or applied again.
>
> Or just fix it upstream with #ifdef __KERNEL__ tags once and for all,
> right?

I wasn't even talking about #ifdef __KERNEL__ issues, although yes those
exist too.

Regards,

Hans