OpenNi in Debian

[Hans-Christoph Steiner]

On Jun 19, 2011, at 3:05 AM, Jochen Sprickerhof wrote:

> * Hans-Christoph Steiner <hans at eds.org> [2011-06-19 00:07]:
>>
>> On Wed, 08 Jun 2011 03:07 +0200, "Jochen Sprickerhof"
>> <jochen at sprickerhof.de> wrote:
>>> * Hans-Christoph Steiner <hans at eds.org> [2011-06-07 18:47]:
>>>>
>>>> On Jun 7, 2011, at 6:44 PM, Jochen Sprickerhof wrote:
>>>>
>>>>> * Hans-Christoph Steiner <hans at eds.org> [2011-06-06 13:05]:
>>>>>>
>>>>>> I have not been in contact with avin.  Is Bayer images support
>>>>>> something that is in the original from PrimeSense, or something  
>>>>>> that
>>>>>> you want added?  If the idea is to maintain new features in the
>>>>>> package, I think that should probably be done in a separate git  
>>>>>> repo
>>>>>> to keep the development and the packaging separately.  If you  
>>>>>> want
>>>>>> to maintain a fork of the primesense/sensor repo, we could base  
>>>>>> the
>>>>>> package off of that for now.
>>>>>
>>>>> it's something we have added. Should we put it on github and  
>>>>> merge it
>>>>> with the avin2 branch?
>>>>
>>>>
>>>> That works for me.
>>>
>>> Here it is: https://github.com/ros-pkg-git/Sensor/tree/master.  
>>> It's not
>>> based on the avin2 branch (as they are not really based to the  
>>> official
>>> OpenNI once), let me know if you that's ok for you. By the way,  
>>> why is
>>> the Debian git not connected to the github one? I mean this one:
>>> http://anonscm.debian.org/gitweb/?p=pkg-multimedia/primesense-kinect-sensor.git
>>
>> These packages are packaged using standard Debian git-buildpackage
>> style.  That means that the upstream code is imported from release
>> tarballs, and the git master branch is all about the debian  
>> packaging.
>> That's why this repo is not a fork of the upstream repo.
>
> According to the git-buildpackage documentation [1] the upstream- 
> branch
> can either be imported or a branch you can pull from. So generating
> tarballs from a git and then importing them into git again seems to be
> superfluous and makes the upstream branch hard to track. But if it  
> works
> for you, I'm fine with it.
>
>> So if we decide to make primesense-kinect-sensor based off of your  
>> git
>> fork, then a release tarball would need to be imported using
>> git-import-orig. I'm thinking perhaps its a better idea if you make a
>> separate package of your fork.  I used the avin2 fork rather than the
>> offical repo for this package because it seems that the official  
>> sources
>> don't fully work.  It should be really easy to create a ros package
>> since the code is so close.  It could be something like
>> primesense-kinect-sensor-ros or whatever.
>
> This has nothing to do with ROS (apart from that it's living in their
> repository. I'm one of the authors of PCL [2] where we use the  
> features
> of my version. As there is a ITP [3] for it, it would be nice if the
> package would include it, so the OpenNI part of PCL would work as  
> well,
> once it's packages.
> Regarding the base for the package I'm fine with the avin2 fork, as  
> long
> as we can put the Bayer patches from my branch inside debian/patches,
> but for me it would almost make more sense to base it of the OpenNI
> branch (as this is the official version) and put the avin2 patches in
> debian/patches as well.

> [1] /usr/share/doc/git-buildpackage/manual-html/ 
> gbp.intro.html#GBP.REPOSITORY
> [2] http://pointclouds.org
> [3] http://bugs.debian.org/624178

Sounds to me like you are much deeper in this code than I am, so I  
would defer to you on that topic :)  I'm mostly am thinking of the  
long term policy for this package, and what makes sense for the code  
that's out there.  So I don't have strong opinions on how it shaped  
for the most part.  My guess is that the package should try to stick  
to the primesense code as much as possible, as long as they are  
accepting patches so that their codebase is usable for Debian.  So  
yes, all changes as patches in debian/patches makes sense to me.

I've mostly achieved my goal, which was making it really easy to use  
skeleton tracking with other media software, but I'm happy to stay  
involved as much as I am useful.  I'm about to have a baby, so I'll  
probably be not around for a while, so don't worry about waiting on me  
to get stuff done.

> Speaking of it, did you see the Fedora patches
> over there [4]?
> [4] https://github.com/OpenNI/OpenNI/pull/10]


That looks very useful, I hope they accept it.

.hc






----------------------------------------------------------------------------

"It is convenient to imagine a power beyond us because that means we  
don't have to examine our own lives.", from "The Idols of  
Environmentalism", by Curtis White