Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-09-01 Thread Jonas Smedegaard

On Tue, Aug 31, 2010 at 10:05:19PM -0400, Alexandre Quessy wrote:

Thanks a lot Jonas and everyone!
I followed the end of this thread and learn a little bit more from it.
I learned some rudiments of Debian, plus git-buildpackage in this
process. I'll learn more in the next ones, and with this one ore later
on as well.
Thanks again!


Well, thanks for your patience!

:-)


 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Jonas Smedegaard

On Mon, Aug 30, 2010 at 10:26:12PM -0400, Alexandre Quessy wrote:

Hello everyone

2010/8/17 Alexandre Quessy alexan...@quessy.net:

2010/8/15 Alexandre Quessy alexan...@quessy.net:

2010/8/15 Jonas Smedegaard d...@jones.dk:
Manpage of milhouse says There is also a shared video library. If 
we expect this to be ever used, we should not ship the header files 
together with the binary (in scenic-utils) but instead provide 
libscenic (or is that the proper name? that's the folder - there 
seem to be no central library in it) and libscenic-dev packages.




I think it would like to see this bug closed:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584164
It's been three (3) months that we're working on this, and no package 
has been done.


I think the shared libraries in this package are not mature enough to 
be public. Therefore, it should not be packaged separately. That means 
that scenic is ready to be uploaded to Debian unstable.


Jonas, please list whatever needs to be done for this package to be 
uploaded.


Ok.  I am preparing an official release now.


 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Jonas Smedegaard

On Mon, Aug 30, 2010 at 10:26:12PM -0400, Alexandre Quessy wrote:

Hello everyone

2010/8/17 Alexandre Quessy alexan...@quessy.net:

2010/8/15 Alexandre Quessy alexan...@quessy.net:

2010/8/15 Jonas Smedegaard d...@jones.dk:
Manpage of milhouse says There is also a shared video library. If 
we expect this to be ever used, we should not ship the header files 
together with the binary (in scenic-utils) but instead provide 
libscenic (or is that the proper name? that's the folder - there 
seem to be no central library in it) and libscenic-dev packages.




I think it would like to see this bug closed:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584164
It's been three (3) months that we're working on this, and no package
has been done.

I think the shared libraries in this package are not mature enough to 
be public. Therefore, it should not be packaged separately. That means 
that scenic is ready to be uploaded to Debian unstable.


Jonas, please list whatever needs to be done for this package to be 
uploaded.


I am not sure how to properly package non-public shared libraries.

Please someone advice on this.


Kind regards,

  -Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Felipe Sateler
On 31/08/10 08:41, Jonas Smedegaard wrote:

 I am not sure how to properly package non-public shared libraries.
 
 Please someone advice on this.

Install  into /usr/lib/package and use RPATH on the executables using
it. If upstream uses autotools, I think just passing an appropriate
libdir will do the right thing.

-- 
Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Reinhard Tartler
On Tue, Aug 31, 2010 at 14:41:47 (CEST), Jonas Smedegaard wrote:

 On Mon, Aug 30, 2010 at 10:26:12PM -0400, Alexandre Quessy wrote:
Hello everyone

2010/8/17 Alexandre Quessy alexan...@quessy.net:
 2010/8/15 Alexandre Quessy alexan...@quessy.net:
 2010/8/15 Jonas Smedegaard d...@jones.dk:
 Manpage of milhouse says There is also a shared video library. If
 we expect this to be ever used, we should not ship the header files
 together with the binary (in scenic-utils) but instead provide
 libscenic (or is that the proper name? that's the folder - there
 seem to be no central library in it) and libscenic-dev packages.


I think it would like to see this bug closed:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584164
It's been three (3) months that we're working on this, and no package
has been done.

 I think the shared libraries in this package are not mature enough to
 be public. Therefore, it should not be packaged separately. That means
 that scenic is ready to be uploaded to Debian unstable.

 Jonas, please list whatever needs to be done for this package to be
 uploaded.

 I am not sure how to properly package non-public shared libraries.

 Please someone advice on this.

really depends on how the package uses them. In general, putting them
into /usr/lib/$package/ should do it, but it really depends on how the
package uses them. are they used as plugins like in xine, vlc? or are
they convenience shared libraries, like e.g. in openoffice?

where do  upstream's installation scripts install them?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Jonas Smedegaard

On Tue, Aug 31, 2010 at 11:10:03AM -0400, Felipe Sateler wrote:

On 31/08/10 08:41, Jonas Smedegaard wrote:


I am not sure how to properly package non-public shared libraries.

Please someone advice on this.


Install into /usr/lib/package and use RPATH on the executables using 
it. If upstream uses autotools, I think just passing an appropriate 
libdir will do the right thing.


So http://wiki.debian.org/RpathIssue do not apply to all shared libs, 
only public ones?




Currently the package generates an shlibs file and ldconfig snippets in 
postinst and postrm scripts.  Lintian then complains with these:


W: scenic-utils: postinst-has-useless-call-to-ldconfig
W: scenic-utils: postrm-has-useless-call-to-ldconfig

Is it wrong of dh_shlideps to include subdirectory below /usr/lib?

Is it sane to pass -X/usr/lib to dh_shlibdeps to suppress it?


Kind regards,

 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Jonas Smedegaard

On Tue, Aug 31, 2010 at 05:23:55PM +0200, Reinhard Tartler wrote:

On Tue, Aug 31, 2010 at 14:41:47 (CEST), Jonas Smedegaard wrote:


On Mon, Aug 30, 2010 at 10:26:12PM -0400, Alexandre Quessy wrote:

Hello everyone

2010/8/17 Alexandre Quessy alexan...@quessy.net:

2010/8/15 Alexandre Quessy alexan...@quessy.net:

2010/8/15 Jonas Smedegaard d...@jones.dk:
Manpage of milhouse says There is also a shared video library. 
If we expect this to be ever used, we should not ship the header 
files together with the binary (in scenic-utils) but instead 
provide libscenic (or is that the proper name? that's the folder 
- there seem to be no central library in it) and libscenic-dev 
packages.




I think it would like to see this bug closed:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584164
It's been three (3) months that we're working on this, and no package 
has been done.


I think the shared libraries in this package are not mature enough 
to be public. Therefore, it should not be packaged separately. That 
means that scenic is ready to be uploaded to Debian unstable.


Jonas, please list whatever needs to be done for this package to be 
uploaded.


I am not sure how to properly package non-public shared libraries.

Please someone advice on this.


really depends on how the package uses them. In general, putting them
into /usr/lib/$package/ should do it, but it really depends on how the
package uses them. are they used as plugins like in xine, vlc? or are
they convenience shared libraries, like e.g. in openoffice?

where do  upstream's installation scripts install them?


As quoted above, it is normal shared libraries which upstream simply 
consider immature for public use.


Personally I suspect that as such we really should treat them as normal 
public shared libraries anyway for Debian packaging (as I suspect we 
might run into similar packaging upgrade problems no matter how stable 
upstram consider the files), but I might be unaware of other acceptable 
approaches.


Upstream install the files below /usr/lib/scenic/


 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Reinhard Tartler
On Tue, Aug 31, 2010 at 17:44:38 (CEST), Jonas Smedegaard wrote:

 On Tue, Aug 31, 2010 at 11:10:03AM -0400, Felipe Sateler wrote:
On 31/08/10 08:41, Jonas Smedegaard wrote:

 I am not sure how to properly package non-public shared libraries.

 Please someone advice on this.

 Install into /usr/lib/package and use RPATH on the executables using
 it. If upstream uses autotools, I think just passing an appropriate
 libdir will do the right thing.

 So http://wiki.debian.org/RpathIssue do not apply to all shared libs,
 only public ones?

yes. and BTW, I find rpath very acceptable for purely private shared
libraries. And even during development and local deployment, rpath is
pretty convenient.

 Currently the package generates an shlibs file and ldconfig snippets in
 postinst and postrm scripts.  Lintian then complains with these:

 W: scenic-utils: postinst-has-useless-call-to-ldconfig
 W: scenic-utils: postrm-has-useless-call-to-ldconfig

ldconfig only indexes /lib and /usr/lib (and a few corner cases, but not
/usr/lib/$package, this is the point of putting them there)

 Is it wrong of dh_shlideps to include subdirectory below /usr/lib?

yes, because you do want to include the private libraries's library
dependencies, don't you?

 Is it sane to pass -X/usr/lib to dh_shlibdeps to suppress it?

no, see above.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Reinhard Tartler
On Tue, Aug 31, 2010 at 18:06:06 (CEST), Jonas Smedegaard wrote:

really depends on how the package uses them. In general, putting them
into /usr/lib/$package/ should do it, but it really depends on how the
package uses them. are they used as plugins like in xine, vlc? or are
they convenience shared libraries, like e.g. in openoffice?

where do  upstream's installation scripts install them?

 As quoted above, it is normal shared libraries which upstream simply
 consider immature for public use.

that's fair.

 Personally I suspect that as such we really should treat them as normal
 public shared libraries anyway for Debian packaging

well, I suspect upstream considers them immature and instable for a
reason, no?

 (as I suspect we might run into similar packaging upgrade problems no
 matter how stable upstram consider the files), but I might be unaware
 of other acceptable approaches.

 Upstream install the files below /usr/lib/scenic/

the obvious approach: just leave them there and be done with it. what
problem do you try to solve?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Jonas Smedegaard

On Tue, Aug 31, 2010 at 06:49:38PM +0200, Reinhard Tartler wrote:

On Tue, Aug 31, 2010 at 18:06:06 (CEST), Jonas Smedegaard wrote:

really depends on how the package uses them. In general, putting them 
into /usr/lib/$package/ should do it, but it really depends on how 
the package uses them. are they used as plugins like in xine, vlc? or 
are they convenience shared libraries, like e.g. in openoffice?


where do upstream's installation scripts install them?


As quoted above, it is normal shared libraries which upstream simply 
consider immature for public use.


that's fair.

Personally I suspect that as such we really should treat them as 
normal public shared libraries anyway for Debian packaging


well, I suspect upstream considers them immature and instable for a 
reason, no?


Sure - what I challenged was not the fact that it is unstable, but if 
perhaps we as distribution might have other concerns tied to our 
packaging upgrade mechanisms.




(as I suspect we might run into similar packaging upgrade problems no 
matter how stable upstram consider the files), but I might be unaware 
of other acceptable approaches.


Upstream install the files below /usr/lib/scenic/


the obvious approach: just leave them there and be done with it. what 
problem do you try to solve?


First I try to understand if there _is_ a problem :-)

What triggered my concern was those lintian warnings that I mentioned in 
the other subthread.



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Jonas Smedegaard

On Tue, Aug 31, 2010 at 06:48:21PM +0200, Reinhard Tartler wrote:

On Tue, Aug 31, 2010 at 17:44:38 (CEST), Jonas Smedegaard wrote:


On Tue, Aug 31, 2010 at 11:10:03AM -0400, Felipe Sateler wrote:

On 31/08/10 08:41, Jonas Smedegaard wrote:


I am not sure how to properly package non-public shared libraries.

Please someone advice on this.


Install into /usr/lib/package and use RPATH on the executables 
using it. If upstream uses autotools, I think just passing an 
appropriate libdir will do the right thing.


So http://wiki.debian.org/RpathIssue do not apply to all shared libs, 
only public ones?


yes. and BTW, I find rpath very acceptable for purely private shared 
libraries. And even during development and local deployment, rpath is 
pretty convenient.


I do not doubt that rpath has sane uses.  What I assumed obvious but can 
state explicitly now to avoid possible confusion, is that my concern 
here is tied to official Debian packaging - not e.g. local deployment.


Do you mean to say that *for* *Official* *Debian* *packaging* it is safe 
to ship shared libraries with rpath when not installed in ldconfig 
supported paths?



Currently the package generates an shlibs file and ldconfig snippets 
in postinst and postrm scripts.  Lintian then complains with these:


W: scenic-utils: postinst-has-useless-call-to-ldconfig
W: scenic-utils: postrm-has-useless-call-to-ldconfig


ldconfig only indexes /lib and /usr/lib (and a few corner cases, but 
not /usr/lib/$package, this is the point of putting them there)



Is it wrong of dh_shlideps to include subdirectory below /usr/lib?


yes, because you do want to include the private libraries's library 
dependencies, don't you?



Is it sane to pass -X/usr/lib to dh_shlibdeps to suppress it?


no, see above.


Sorry - I am confused: why not suppress wrongly included private shared 
libraries from being registered by dh_shlibdeps?



Kind regards,

 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Reinhard Tartler
On Tue, Aug 31, 2010 at 20:50:05 (CEST), Jonas Smedegaard wrote:

 On Tue, Aug 31, 2010 at 06:48:21PM +0200, Reinhard Tartler wrote:
On Tue, Aug 31, 2010 at 17:44:38 (CEST), Jonas Smedegaard wrote:

 On Tue, Aug 31, 2010 at 11:10:03AM -0400, Felipe Sateler wrote:
On 31/08/10 08:41, Jonas Smedegaard wrote:

 I am not sure how to properly package non-public shared libraries.

 Please someone advice on this.

 Install into /usr/lib/package and use RPATH on the executables
 using it. If upstream uses autotools, I think just passing an
 appropriate libdir will do the right thing.

 So http://wiki.debian.org/RpathIssue do not apply to all shared libs,
 only public ones?

 yes. and BTW, I find rpath very acceptable for purely private shared
 libraries. And even during development and local deployment, rpath is
 pretty convenient.

 I do not doubt that rpath has sane uses.  What I assumed obvious but can
 state explicitly now to avoid possible confusion, is that my concern
 here is tied to official Debian packaging - not e.g. local deployment.

 Do you mean to say that *for* *Official* *Debian* *packaging* it is safe
 to ship shared libraries with rpath when not installed in ldconfig
 supported paths?

Yes, I do.


 Currently the package generates an shlibs file and ldconfig snippets
 in postinst and postrm scripts.  Lintian then complains with these:

 W: scenic-utils: postinst-has-useless-call-to-ldconfig
 W: scenic-utils: postrm-has-useless-call-to-ldconfig

 ldconfig only indexes /lib and /usr/lib (and a few corner cases, but
 not /usr/lib/$package, this is the point of putting them there)

 Is it wrong of dh_shlideps to include subdirectory below /usr/lib?

 yes, because you do want to include the private libraries's library
 dependencies, don't you?

 Is it sane to pass -X/usr/lib to dh_shlibdeps to suppress it?

no, see above.

 Sorry - I am confused: why not suppress wrongly included private shared
 libraries from being registered by dh_shlibdeps?

because you do want to consider their library dependencies

(these shared libraries might have dependencies on other shared
libraries themselves!)

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Jonas Smedegaard

On Tue, Aug 31, 2010 at 10:32:50PM +0200, Reinhard Tartler wrote:

On Tue, Aug 31, 2010 at 20:50:05 (CEST), Jonas Smedegaard wrote:


On Tue, Aug 31, 2010 at 06:48:21PM +0200, Reinhard Tartler wrote:

On Tue, Aug 31, 2010 at 17:44:38 (CEST), Jonas Smedegaard wrote:


On Tue, Aug 31, 2010 at 11:10:03AM -0400, Felipe Sateler wrote:

On 31/08/10 08:41, Jonas Smedegaard wrote:

I am not sure how to properly package non-public shared 
libraries.


Please someone advice on this.


Install into /usr/lib/package and use RPATH on the executables 
using it. If upstream uses autotools, I think just passing an 
appropriate libdir will do the right thing.


So http://wiki.debian.org/RpathIssue do not apply to all shared 
libs, only public ones?


yes. and BTW, I find rpath very acceptable for purely private shared 
libraries. And even during development and local deployment, rpath 
is pretty convenient.


I do not doubt that rpath has sane uses.  What I assumed obvious but 
can state explicitly now to avoid possible confusion, is that my 
concern here is tied to official Debian packaging - not e.g. local 
deployment.


Do you mean to say that *for* *Official* *Debian* *packaging* it is 
safe to ship shared libraries with rpath when not installed in 
ldconfig supported paths?


Yes, I do.



Currently the package generates an shlibs file and ldconfig 
snippets in postinst and postrm scripts.  Lintian then complains 
with these:


W: scenic-utils: postinst-has-useless-call-to-ldconfig
W: scenic-utils: postrm-has-useless-call-to-ldconfig


ldconfig only indexes /lib and /usr/lib (and a few corner cases, but 
not /usr/lib/$package, this is the point of putting them there)



Is it wrong of dh_shlideps to include subdirectory below /usr/lib?


yes, because you do want to include the private libraries's library 
dependencies, don't you?



Is it sane to pass -X/usr/lib to dh_shlibdeps to suppress it?


no, see above.


Sorry - I am confused: why not suppress wrongly included private 
shared libraries from being registered by dh_shlibdeps?


because you do want to consider their library dependencies

(these shared libraries might have dependencies on other shared 
libraries themselves!)


Ah, I get it now - yes, I was indeed confused: I meant dh_makeshlibs. 
:-)



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Alexandre Quessy
Thanks a lot Jonas and everyone!
I followed the end of this thread and learn a little bit more from it.
I learned some rudiments of Debian, plus git-buildpackage in this
process. I'll learn more in the next ones, and with this one ore later
on as well.
Thanks again!
-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-31 Thread Reinhard Tartler
On Wed, Sep 01, 2010 at 02:38:41 (CEST), Jonas Smedegaard wrote:

 Sorry - I am confused: why not suppress wrongly included private
 shared libraries from being registered by dh_shlibdeps?

because you do want to consider their library dependencies

 (these shared libraries might have dependencies on other shared
 libraries themselves!)

 Ah, I get it now - yes, I was indeed confused: I meant
 dh_makeshlibs. :-)

indeed, this helper creates a shlibs file, which should only be done for
public libraries.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-30 Thread Alexandre Quessy
Hello everyone

2010/8/17 Alexandre Quessy alexan...@quessy.net:
 2010/8/15 Alexandre Quessy alexan...@quessy.net:
 2010/8/15 Jonas Smedegaard d...@jones.dk:
 Manpage of milhouse says There is also a shared video library. If we
 expect this to be ever used, we should not ship the header files together
 with the binary (in scenic-utils) but instead provide libscenic (or is that
 the proper name? that's the folder - there seem to be no central library in
 it) and libscenic-dev packages.


I think it would like to see this bug closed:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584164
It's been three (3) months that we're working on this, and no package
has been done.

I think the shared libraries in this package are not mature enough to
be public. Therefore, it should not be packaged separately. That means
that scenic is ready to be uploaded to Debian unstable.

Jonas, please list whatever needs to be done for this package to be uploaded.

Thank you.
-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-17 Thread Alexandre Quessy
Hello Jonas,
Here is a little update about the libscenic-dev that we should create as well.

(I have never packaged C++ libraries. Should be relatively simple, no?)

2010/8/15 Alexandre Quessy alexan...@quessy.net:
 2010/8/15 Jonas Smedegaard d...@jones.dk:
 Manpage of milhouse says There is also a shared video library. If we
 expect this to be ever used, we should not ship the header files together
 with the binary (in scenic-utils) but instead provide libscenic (or is that
 the proper name? that's the folder - there seem to be no central library in
 it) and libscenic-dev packages.

 That's right. I thought about this. There is no central library/header
 called scenic, but rather a few libraries that are in a directory
 called scenic. I think libscenic is the name it should have. The files
 that are intended to be public are:

 ./usr/include/scenic/videoSize.h
 ./usr/include/scenic/sharedVideoBuffer.h
 ./usr/lib/scenic/libshared_video.*


That libscenic-dev library should have the following dependencies :

 libboost-dev,
 libboost-thread-dev,
 libboost-date-time-dev,
 libboost-system-dev

Best,
-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-15 Thread Jonas Smedegaard

On Fri, Aug 06, 2010 at 09:59:27AM -0400, Alexandre Quessy wrote:

Hello again,

2010/7/31 Alexandre Quessy alexan...@quessy.net:

2010/7/26 Jonas Smedegaard jo...@jones.dk:

Ok.


So? Are we close to the upload time? It seems to me we have solved 
the most important issues with this packaging. The version packaged 
is now the latest of the 0.6 stable branch. This software will be a 
useful contribution to Debian, I believe.


Any ETA on this? :)
(sorry to keep pinging you)
I think this package is a good candidate to be part of squeeze, the
next release of Debian.


Sorry - have been busy elsewhere.  I am fine with you pinging me - 
doesn't annoy me at all, au contrare.


We did not make it for Debian Squeeze, unfortunately: It was declared 
frozen approx. a week ago. :-/


Manpage of milhouse says There is also a shared video library. If we 
expect this to be ever used, we should not ship the header files 
together with the binary (in scenic-utils) but instead provide libscenic 
(or is that the proper name? that's the folder - there seem to be no 
central library in it) and libscenic-dev packages.


Also, milhouse looks like a daemon - would it perhaps make sense to 
start it with a sysV script?



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-15 Thread Alexandre Quessy
Hello Jonas,
I see you have done more work on these packages. Nice.

2010/8/15 Jonas Smedegaard d...@jones.dk:
 Sorry - have been busy elsewhere.  I am fine with you pinging me - doesn't
 annoy me at all, au contrare.

Ok. Yes, it brings up the email thread in the mail box. :)

 We did not make it for Debian Squeeze, unfortunately: It was declared frozen
 approx. a week ago. :-/

Too bad. :-(

 Manpage of milhouse says There is also a shared video library. If we
 expect this to be ever used, we should not ship the header files together
 with the binary (in scenic-utils) but instead provide libscenic (or is that
 the proper name? that's the folder - there seem to be no central library in
 it) and libscenic-dev packages.

That's right. I thought about this. There is no central library/header
called scenic, but rather a few libraries that are in a directory
called scenic. I think libscenic is the name it should have. The files
that are intended to be public are:

./usr/include/scenic/videoSize.h
./usr/include/scenic/sharedVideoBuffer.h
./usr/lib/scenic/libshared_video.*

The other file do not need to be public.

 Also, milhouse looks like a daemon - would it perhaps make sense to start it
 with a sysV script?

It's a command-line tool to stream, but is unidirectional and should
be stopped and started often by the user, depending on his needs. It's
the scenic Python application that is a GUI front-end to it that is
most often used by the user. (or milhouse using scripts) So, no, a
sysV script would not be wanted.

-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-08-06 Thread Alexandre Quessy
Hello again,

2010/7/31 Alexandre Quessy alexan...@quessy.net:
 2010/7/26 Jonas Smedegaard jo...@jones.dk:
 Ok.

 So? Are we close to the upload time? It seems to me we have solved the
 most important issues with this packaging. The version packaged is now
 the latest of the 0.6 stable branch. This software will be a useful
 contribution to Debian, I believe.

Any ETA on this? :)
(sorry to keep pinging you)
I think this package is a good candidate to be part of squeeze, the
next release of Debian.

Best,
-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-07-26 Thread Jonas Smedegaard

On Sun, Jul 25, 2010 at 09:06:34PM -0400, Alexandre Quessy wrote:

2010/7/22 Jonas Smedegaard jo...@jones.dk:

I am having another look at it now...


Thanks for those fixes you have done. I was close to something that 
works with my scenic.install and midistream.install files. Now, thanks 
to you, each Python files go in the right package.


I only find somewhat strange that there are no *.pyc nor .pyo files 
anywhere. Is that normal?


Yes.  They are stripped by python-autotools.mk (as they should be 
according to Debian Python Policy) and regenerated at package install 
time.



For the help2man call with not-yet-built Python modules, we (upstream) 
are trying to make it done only at make dist time, but it seemed to 
fail. They can fix that later upstream. :)


Ok.


 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-07-25 Thread Alexandre Quessy
Hello Jonas,

2010/7/22 Jonas Smedegaard jo...@jones.dk:
 I am having another look at it now...

Thanks for those fixes you have done. I was close to something that
works with my scenic.install and midistream.install files. Now, thanks
to you, each Python files go in the right package.

I only find somewhat strange that there are no *.pyc nor .pyo files
anywhere. Is that normal?

For the help2man call with not-yet-built Python modules, we (upstream)
are trying to make it done only at make dist time, but it seemed to
fail. They can fix that later upstream. :)

Best regards,
-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-07-22 Thread Alexandre Quessy
Hello Jonas and all,

2010/7/20 Jonas Smedegaard jo...@jones.dk:
 On Tue, Jul 20, 2010 at 12:16:38PM -0400, Alexandre Quessy wrote:
 On 10-07-20 12:07 PM, Alexandre Quessy wrote:
  2) Replace the shebang by the proper Python version

 We still need to set up the /usr/bin/python2.6 thing.

That's still to do. I think it's to be done in the Debian packaging.
(the upstream authors can really well apply some patches later on)


 Also, I have problems with installing the Python modules in the right
 package. (the scenic and midistream binary packages are the ones that
 contain Python modules. Namely the scenic and midistream modules)

 Do you mean we as upstream or hack it in packaging?


I meant we as the Debian packagers. I think the Python work is OK
upstream. Now, we just need to package it for Debian. There are two
Python modules and some Python executables. I wanted to create two
packages for this: scenic and midistream. Upstream, it's all packaged
using the autotools.

Best regards,
-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-07-22 Thread Jonas Smedegaard

On Thu, Jul 22, 2010 at 02:28:11PM -0400, Alexandre Quessy wrote:

2010/7/20 Jonas Smedegaard jo...@jones.dk:

On Tue, Jul 20, 2010 at 12:16:38PM -0400, Alexandre Quessy wrote:

On 10-07-20 12:07 PM, Alexandre Quessy wrote:

 2) Replace the shebang by the proper Python version


We still need to set up the /usr/bin/python2.6 thing.


That's still to do. I think it's to be done in the Debian packaging. 
(the upstream authors can really well apply some patches later on)


Ok.


Also, I have problems with installing the Python modules in the 
right package. (the scenic and midistream binary packages are the 
ones that contain Python modules. Namely the scenic and midistream 
modules)


Do you mean we as upstream or hack it in packaging?



I meant we as the Debian packagers. I think the Python work is OK 
upstream. Now, we just need to package it for Debian. There are two 
Python modules and some Python executables. I wanted to create two 
packages for this: scenic and midistream. Upstream, it's all packaged 
using the autotools.


Ok.


I am having another look at it now...


 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-07-20 Thread Alexandre Quessy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Jonas and the team,

I'm finally managing to put some more time on this. I spent a few weeks
without much Internet access. Meanwhile, we applied you patch upstream
and made a new release. There are issues to fix, though, since we
changed the way the Python is packaged with autotools.

On 10-06-21 12:04 PM, Jonas Smedegaard wrote:
 On Mon, Jun 21, 2010 at 10:58:47AM -0400, Alexandre Quessy wrote:

 What I know for sure, is that the Python modules are not shipped with
 any Debian package anymore. :(
 
 Yeah, I did not dispute that, and do not even claim to know for sure
 that your attempts are wrong, only that they _seem_ wrong from a quick
 glance.
 
 When the below build problems have been solved or worked around, I can
 actually build some packages and _then_ help figure out how to solve
 above issue.
 

Hmmm. Actually, our release doesn't quit fix these. I guess it's better
to apply patches and then push them upstream. (remove my author hat, and
wear the packager one) You were right about this.

 
 Python scripts are invoked directly, causing default Python to always
 be used, ignoring autotools $(PYTHON) variable.  This is only an
 issue on systems that wants to build for a non-default Python version
 (i.e. not currently a problem with Debian). I believe the best fix is
 to use the autotools-provided $(PYTHON) (and the related python
 prefix variable - I forgot its variable name) to compose the hashbang
 from a .in file of the scripts, instead of the current /usr/bin/env
 python construct.


 Reading the automake manual (#1) I guess it could be $(PYTHON_VERSION).

 #1: http://www.gnu.org/software/hello/manual/automake/Python.html

 Since the scripts have some automake variables already expanded, I
 could put #!/usr/bin/python@@PYTHON_VERSION@@ there, or something
 similar?
 
 I am no expert in autotools, so do not know what is the most proper or
 elegant approach.  I just wanted to point out that to me it seems the
 problem lies somewhere in the autotools files.
 
 If (as is seems) you are not familiar with (Python-specific parts of)
 autotools either, then I suggest looking at other project for
 inspiration on how they do things, and use official documentation only
 for reference and verification rather than as educational tool.
 

I will ask around for help on this.

 
 Python scripts rely on local modules that are a) not declared and b)
 not yet built.  I fixed a) with a patch, but b) still fails.  I
 believe the help2man rules need to depend on module building, and the
 patch then changed to use build dir instead of source dir (which is
 wrong to use in any case).


 I think this is the most critical issue right now.
 
 Indeed: This is what made me give up for now trying to actually fully
 build packages so that I could help figure out how to most properly
 include the Python parts.
 
 
 Help2man calls the Python scripts, which it turn makes Python
 byte-compile the modules with the wrong Python version. (?) To fix
 this, the man page rule in man/Makefile.am should depend on building
 the Python modules.

 What target would that be ? scenic_PYTHON and rtpmidi_PYTHON ?
 
 Sorry - don't know :-( .  But sounds like you are looking in the right
 direction (if that is of any help or at least of some encouragement).
 

Ah! We thought about putting the call to help2man in the make dist
target, not make. We would put them in the tarball, but they would not
be rebuilt when running git-buildpackage. That would solve this issue.
(the *.pyc files are not distributed in the tarball)

 
 Another more annoying issue is that upstream autotools do not use
 AM_MAINTAINER_MODE, causing normal builds to regenerate autotools if
 too old which might happen accidentally, especially when using a
 VCS as we do.  The fix upstream is simple: Add AM_MAINTAINER_MODE to
 configure.am and all should be fine.  Until then we need to do a
 clumsy workaround of preserving upstream autotools and restoring in
 our clean rule.


 I just filled a bug (#2) report upstream about it. It will be in the
 next release.
 

Fixed in upstream 0.6.3.

Ok, so we have two major bugs to fix.
 1) Call help2man in the make dist target and distribute the man pages
in the tarball.
 2) Replace the shebang by the proper Python version

It seems to me that packaging Python stuff is so difficult that it's
what is actually slowing down the whole release of the next stable
Debian. At least, that's my impression reading
http://en.wikipedia.org/wiki/Debian#Release_history

Not giving up!

Alex
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMRcnWAAoJEJQ0pOgl2qx1iTUP+wfk66Z0apOjQ+mO84KbU/8U
tNuMD2Vzabzo+aWvQ+m/wgbQGaNJHAPTfN2nx0puWwR7R5AeBehkZVD37kq+BGmM
CfOvznxMrZfiriJZvlrx+sF7uVIciDVbXmh/9oo/XhS/Ps59cHBIx0e4hA+BF7E6
v+U8ufPlD79tZR7Rxyg+4sT5tj/fOWDD0Od+y5RnNCNB/tlVxDOhgac00sUhiMUA

Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-07-20 Thread Alexandre Quessy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello again,
I just remebered that the man page bug has been fixed upstream! They are
now distributed with the tarball, and not rebuilt by git-buildpackage.

On 10-07-20 12:07 PM, Alexandre Quessy wrote:
 
 Ok, so we have two major bugs to fix.
  1) Call help2man in the make dist target and distribute the man pages
 in the tarball.
  2) Replace the shebang by the proper Python version
 

We still need to set up the /usr/bin/python2.6 thing.

Also, I have problems with installing the Python modules in the right
package. (the scenic and midistream binary packages are the ones that
contain Python modules. Namely the scenic and midistream modules)

a
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMRcvmAAoJEJQ0pOgl2qx1eYEP/RRuMKZAi/WhkKJ6QaqZqHZB
asyGtiK2hyr9zMQSJ/ORfQnvxm+o0YCgSqtuOOcdmSt2Vcpq2asqRxsGrKxBRgSK
xNE4+znU7jjnhJ3r0ywBIQNxDCN4H0W2VqTjfzT4Q349GHEDH4/QJToJi9Zsefst
KUwxCxKcKP/QUFvo6KJ2JOzucNLJFY/4gsa0XIaOlQX2u3EEMt08sqhLSpayLc5H
NRl8YDaFddNzB1n2rmf+F2MSiOzsfLZwqNUJRcrQrO6+Xn7e0H5SdGFBXP47oVNN
ALhZy94Y0pzAX5fVD7OQApvYS7+PrPOa0bimMx9TPJN9zA/Y9MKt5+8LqiEL1fVl
y5cfjzGdMcZaUj5qcDFRTsIx1V+EAyfKD079vxvAELNSKhmOY4Q5nCaA3X5+qZSA
xlQODCWDT0Qrvo/lG+EnZMRv/sH8aori9bi1JiH/ovMJqxMg8exTMTVzXptdSG4e
9L01AkvanCi1w7aGzKZJJPTq1fAy4PwxpTSWTBRjxPDuozKLB5ECd27HUT5WV+b3
qboDesZezoZ8btBm2vN2qU0jOXAkjAjJ37CL9EHZPudTUjdN3AXypDqa85BzDJ2+
Ltz/7uJYxTzO8UW7r81aD7WR3v4gIsmQ/7vJPJ4gNYWYo77FzfQ3z2b+cGAHkLb2
fFGDpDmhrztqp1EIc331
=SXIC
-END PGP SIGNATURE-

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-07-20 Thread Jonas Smedegaard

Hi Alexandre (and others following this thread),

On Tue, Jul 20, 2010 at 12:16:38PM -0400, Alexandre Quessy wrote:
I just remebered that the man page bug has been fixed upstream! They 
are now distributed with the tarball, and not rebuilt by 
git-buildpackage.


On 10-07-20 12:07 PM, Alexandre Quessy wrote:


Ok, so we have two major bugs to fix.
 1) Call help2man in the make dist target and distribute the man 
pages in the tarball.

 2) Replace the shebang by the proper Python version



We still need to set up the /usr/bin/python2.6 thing.

Also, I have problems with installing the Python modules in the right 
package. (the scenic and midistream binary packages are the ones that 
contain Python modules. Namely the scenic and midistream modules)


Do you mean we as upstream or hack it in packaging?


 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-21 Thread Jonas Smedegaard

Hi Alexandre (and others),

On Sun, Jun 20, 2010 at 11:51:10AM -0400, Alexandre Quessy wrote:

On 10-06-11 07:11 PM, Jonas Smedegaard wrote:


Hmmm. I see now that your Makefile.in for the python code uses 
$(libdir) and not $(pythondir).  This causes the code to not use 
standard Python paths, so that a) it is not possible to support 
multiple concurrent Python versions, and b) you need to explicitly 
tell pysupport where the custom files are stored so that it can 
properly ensure Python Policy is followed.


Right now the files are simply installed - not handled properly :-(



This has been fixed upstream in the release 0.6.2! I imported the new 
tarball in the repository, and it seems to compile OK. What I didn't 
get yet, is how to install the Python module for each binary package.


The scenic Python module should be shipped with the scenic Debian 
package; the rtpmidi Python module with the midistream .deb.


I played with the debian/rules a bit and read more about dh_pysupport. 
I am still not sure of how I should do this. Any suggestion?


 From a quick glance it seems that your latest attempts are wrong.  I had 
a go at compiling now (my earlier laptop disk space problems have been 
solved now!) but unfortunately didn't make it far enough to look at this 
issue.


I improved build-dependencies on Boost libs.  This shouldn't affect the 
buildability.


Python scripts are invoked directly, causing default Python to always be 
used, ignoring autotools $(PYTHON) variable.  This is only an issue on 
systems that wants to build for a non-default Python version (i.e. not 
currently a problem with Debian). I believe the best fix is to use the 
autotools-provided $(PYTHON) (and the related python prefix variable - I 
forgot its variable name) to compose the hashbang from a .in file of the 
scripts, instead of the current /usr/bin/env python construct.


Python scripts rely on local modules that are a) not declared and b) not 
yet built.  I fixed a) with a patch, but b) still fails.  I believe the 
help2man rules need to depend on module building, and the patch then 
changed to use build dir instead of source dir (which is wrong to use in 
any case).


Another issue is weak cleanup.  During build, directories and files are 
created, which are not cleaned up in the clean target.  I have worked 
around this in the packaging by forcefully removing the build directory, 
so not urgent to fix, just would improve elegancy of upstream build 
routines :-)


Another more annoying issue is that upstream autotools do not use 
AM_MAINTAINER_MODE, causing normal builds to regenerate autotools if 
too old which might happen accidentally, especially when using a VCS 
as we do.  The fix upstream is simple: Add AM_MAINTAINER_MODE to 
configure.am and all should be fine.  Until then we need to do a clumsy 
workaround of preserving upstream autotools and restoring in our clean 
rule.



Sorry for my silence - I have been busy with Real Life.  I am really 
excited about this package, as it seems to provide quite cool 
functionality that I am really looking forward to play with :-)


Hope this helps,

  - Jonas

--
  * Jonas Smedegaard - idealist  Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-21 Thread Alexandre Quessy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Jonas and the team,

On 10-06-21 06:38 AM, Jonas Smedegaard wrote:
 
  From a quick glance it seems that your latest attempts are wrong.  I
 had a go at compiling now (my earlier laptop disk space problems have
 been solved now!) but unfortunately didn't make it far enough to look at
 this issue.
 

Sad I was wrong. Happy your disk is back. :)

What I know for sure, is that the Python modules are not shipped with
any Debian package anymore. :(

 I improved build-dependencies on Boost libs.  This shouldn't affect the
 buildability.
 

Ok. I'm taking notes. ;)

I don't know yet how to create patches like that. I gues
git-buildpackage should provide some tools to ease that?

 Python scripts are invoked directly, causing default Python to always be
 used, ignoring autotools $(PYTHON) variable.  This is only an issue on
 systems that wants to build for a non-default Python version (i.e. not
 currently a problem with Debian). I believe the best fix is to use the
 autotools-provided $(PYTHON) (and the related python prefix variable - I
 forgot its variable name) to compose the hashbang from a .in file of the
 scripts, instead of the current /usr/bin/env python construct.
 

Reading the automake manual (#1) I guess it could be $(PYTHON_VERSION).

#1: http://www.gnu.org/software/hello/manual/automake/Python.html

Since the scripts have some automake variables already expanded, I could
put #!/usr/bin/python@@PYTHON_VERSION@@ there, or something similar?

 Python scripts rely on local modules that are a) not declared and b) not
 yet built.  I fixed a) with a patch, but b) still fails.  I believe the
 help2man rules need to depend on module building, and the patch then
 changed to use build dir instead of source dir (which is wrong to use in
 any case).
 

I think this is the most critical issue right now. Help2man calls the
Python scripts, which it turn makes Python byte-compile the modules with
the wrong Python version. (?) To fix this, the man page rule in
man/Makefile.am should depend on building the Python modules.

What target would that be ? scenic_PYTHON and rtpmidi_PYTHON ?

 Another issue is weak cleanup.  During build, directories and files are
 created, which are not cleaned up in the clean target.  I have worked
 around this in the packaging by forcefully removing the build directory,
 so not urgent to fix, just would improve elegancy of upstream build
 routines :-)
 

Yes, I am aware of that. Meanwhile, I am building with `git-buildpackage
- --git-export-dir=../build-area`.

 Another more annoying issue is that upstream autotools do not use
 AM_MAINTAINER_MODE, causing normal builds to regenerate autotools if
 too old which might happen accidentally, especially when using a VCS
 as we do.  The fix upstream is simple: Add AM_MAINTAINER_MODE to
 configure.am and all should be fine.  Until then we need to do a clumsy
 workaround of preserving upstream autotools and restoring in our clean
 rule.
 

I just filled a bug (#2) report upstream about it. It will be in the
next release.

#2: https://svn.sat.qc.ca/trac/scenic/ticket/589

 
 Sorry for my silence - I have been busy with Real Life.  I am really
 excited about this package, as it seems to provide quite cool
 functionality that I am really looking forward to play with :-)
 

Happy to read this. :)

Our team really care about improving audio-video tools offer for
GNU/Linux. We hope this package will be useful, and believe it really
answers a need. (especially for live events and installations)

Thanks for your help!
Alex
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMH34iAAoJEJQ0pOgl2qx1cmgP/2mM35SGOeV/ElfxmCNyIk4k
3z1wH8OZRgcDB5KlvBSPd5wK7dL0CW9IPSzZHVB7I9dzUkAsA0cx4aAIvTjFaxzK
u4ex7Y2KvpivIiRRsow2c1iFommpPlH3aHh8o7t+aC6tOdMQdsDHBdPDAK15P63G
v+BXLVhjOO74oK0uH4tlrptg3LG7B3UBJH4xRBijF5OtVayJf1SUferZMzUR7XcS
klDIdK/Gyxz0CprZTPRlo6jcUjCU2vbpyxhwYIajhxrKqe295okL+WoVgFHNGJKn
hmujBD6qQYAQauAUVR21eboNzmu5q7rNE06TLU66PUd78Xv/Uq08PUeUfGuatl6t
46TlCQjyDyyL8R/fDe1t8L4/HXWxIWlUChMvFDKZ6EPsBO1tXko1XmJ7Ivig5g04
9GR0bYPTkrwZydXJtBmCEjHzuHU1HdtDZdRC8IpHN0RIhDI3C+qjyw+TaIQwGw8R
eJOceOhWUokuElNL/cF/gJR+RRlJD43ccMP/Q8vtGvTGWdMVXmevsTbG2XOuoRSy
XnPst3BRrX4VGJ9gx2dv7eGVpn5z4ZXjmEcG1hLT6PN4JcCm5J0eYQLeVpt+0P2e
58hBOZdkqe35L4TfgtXA1cuzfwsP38lLMlbEebwiz3TRTpdLfRUcQ7qRHIyAvJ0s
FdxY93Uip5EjKyl0TDDP
=1iIi
-END PGP SIGNATURE-

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-21 Thread Jonas Smedegaard

On Mon, Jun 21, 2010 at 10:58:47AM -0400, Alexandre Quessy wrote:

On 10-06-21 06:38 AM, Jonas Smedegaard wrote:


 From a quick glance it seems that your latest attempts are wrong.  I 
had a go at compiling now (my earlier laptop disk space problems have 
been solved now!) but unfortunately didn't make it far enough to look 
at this issue.




Sad I was wrong. Happy your disk is back. :)

What I know for sure, is that the Python modules are not shipped with 
any Debian package anymore. :(


Yeah, I did not dispute that, and do not even claim to know for sure 
that your attempts are wrong, only that they _seem_ wrong from a quick 
glance.


When the below build problems have been solved or worked around, I can 
actually build some packages and _then_ help figure out how to solve 
above issue.




I don't know yet how to create patches like that. I gues
git-buildpackage should provide some tools to ease that?


If you mean the patch I have now added below debian/patches, then read 
the manpage of quilt for info on that.


Personally I simply used diff -ruN and patch -p 1 for many years, 
and only very recently started looking at quilt as a convenience 
wrapper.



Python scripts are invoked directly, causing default Python to always 
be used, ignoring autotools $(PYTHON) variable.  This is only an 
issue on systems that wants to build for a non-default Python version 
(i.e. not currently a problem with Debian). I believe the best fix is 
to use the autotools-provided $(PYTHON) (and the related python 
prefix variable - I forgot its variable name) to compose the hashbang 
from a .in file of the scripts, instead of the current /usr/bin/env 
python construct.




Reading the automake manual (#1) I guess it could be $(PYTHON_VERSION).

#1: http://www.gnu.org/software/hello/manual/automake/Python.html

Since the scripts have some automake variables already expanded, I 
could put #!/usr/bin/python@@PYTHON_VERSION@@ there, or something 
similar?


I am no expert in autotools, so do not know what is the most proper or 
elegant approach.  I just wanted to point out that to me it seems the 
problem lies somewhere in the autotools files.


If (as is seems) you are not familiar with (Python-specific parts of) 
autotools either, then I suggest looking at other project for 
inspiration on how they do things, and use official documentation only 
for reference and verification rather than as educational tool.


...but that's just me.  I know for sure that not all of my working 
methods are most effective ;-)



Python scripts rely on local modules that are a) not declared and b) 
not yet built.  I fixed a) with a patch, but b) still fails.  I 
believe the help2man rules need to depend on module building, and the 
patch then changed to use build dir instead of source dir (which is 
wrong to use in any case).




I think this is the most critical issue right now.


Indeed: This is what made me give up for now trying to actually fully 
build packages so that I could help figure out how to most properly 
include the Python parts.



Help2man calls the Python scripts, which it turn makes Python 
byte-compile the modules with the wrong Python version. (?) To fix 
this, the man page rule in man/Makefile.am should depend on building 
the Python modules.


What target would that be ? scenic_PYTHON and rtpmidi_PYTHON ?


Sorry - don't know :-( .  But sounds like you are looking in the right 
direction (if that is of any help or at least of some encouragement).



Another issue is weak cleanup.  During build, directories and files 
are created, which are not cleaned up in the clean target.  I have 
worked around this in the packaging by forcefully removing the build 
directory, so not urgent to fix, just would improve elegancy of 
upstream build routines :-)




Yes, I am aware of that. Meanwhile, I am building with 
`git-buildpackage - --git-export-dir=../build-area`.


Ah, yes.  That's a good workaround.  One that I seldom take, but that's 
just because I am massochistic and insist that all cleanup must be 
perfect for my packages.


For the above (but not the below) you need no longer do that workaround 
as we use a separate build dir which is forcefully removed from now on.



Another more annoying issue is that upstream autotools do not use 
AM_MAINTAINER_MODE, causing normal builds to regenerate autotools if 
too old which might happen accidentally, especially when using a 
VCS as we do.  The fix upstream is simple: Add AM_MAINTAINER_MODE to 
configure.am and all should be fine.  Until then we need to do a 
clumsy workaround of preserving upstream autotools and restoring in 
our clean rule.




I just filled a bug (#2) report upstream about it. It will be in the 
next release.


Excellent!


 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-20 Thread Alexandre Quessy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello!

On 10-06-11 07:11 PM, Jonas Smedegaard wrote:
 
 Hmmm. I see now that your Makefile.in for the python code uses $(libdir)
 and not $(pythondir).  This causes the code to not use standard Python
 paths, so that a) it is not possible to support multiple concurrent
 Python versions, and b) you need to explicitly tell pysupport where the
 custom files are stored so that it can properly ensure Python Policy is
 followed.
 
 Right now the files are simply installed - not handled properly :-(
 

This has been fixed upstream in the release 0.6.2! I imported the new
tarball in the repository, and it seems to compile OK. What I didn't get
yet, is how to install the Python module for each binary package.

The scenic Python module should be shipped with the scenic Debian
package; the rtpmidi Python module with the midistream .deb.

I played with the debian/rules a bit and read more about dh_pysupport. I
am still not sure of how I should do this. Any suggestion?

Later,
Alexandre
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMHjjpAAoJEJQ0pOgl2qx1K8EP/RAh3P6wNHc2yKpzJFuIaMNw
r+TCrwIxxR/wrkEnfmY/HmILhkdiJVA3RM4t6umny9qvMkvjW/AecbY0cgvlUPxU
QiXFo6Sgfl4hjDMvGo7JPsCFyqrNAllzL2CXWR8V2+Zp+EAHCP1Gy+Ay1knB8vFc
8we0vrDyhXESbLWXljo0UUdgqtr6e+0VPsET3/vXayi0Xq5Vz9Ux6RmmJP+ci6n7
/aAo93S8g4n9JWylurJE1rovqepcNEKexNE9RGjCm3jSaPNBq/KOVSoW/zmW1q98
dWQvhEHQESUFlrJc6gH55v2R0P9gaiOs5Y0sSYn9J7oercuHC61KGGipKAm9vwtS
5NHD8IQYmBX7YoOhjQx3ru1Pg6zXPB9wxc+8vnVa13Sh+f6/cQFB3HDLp0TMAe8n
p9Vw5XElujMdcwACouINeVrSPqigsKo4wZ8rz3L/ks9DsyYMEKj4xmoEXx8GAyr0
MN+cdQ56bBN/16+A9AmIuLrvHVBAJ7nPXyx8imf1HyPzvW0G0xSiWLwHkAgne4Pe
YulT/P0c7rsCzacVl/iBo4b8oCjT19KgssyKU4M0ZfjZYROidybQqX3RxZEaw+OC
jovVGQZy3U1Y7Cr3oLHDPJD8AbKADaSpTAR/x2YWyOWWgXvhdIMxcs0XcWgxDjY/
JItBksZFVNnTQY1sBPTw
=om1l
-END PGP SIGNATURE-

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-12 Thread Jonas Smedegaard

On Sat, Jun 12, 2010 at 10:04:22AM -0400, Alexandre Quessy wrote:

Hello Jonas!

2010/6/11 Jonas Smedegaard jo...@jones.dk:


Hmm.  There is something weird with the pristine-tar data.

Did you use git-import-orig or something custom?



I first used git-import-orig, but it failed, since I had not set up my 
gitconfig with my correct user.name and user.email. It failed with a 
lot of errors. Afterwhile, I tried to fix everything up manually... I 
signed and did some commits, then I merged upstream into master.



Are you sure you did not rename a bzip2 tarball or something?



The upstream tarball is a .tar.gz, not a bz2. I see there are two 
tarballs in the pristine-tar branch. I guess I should remove the old 
one?



Oh - maybe it is simply that you need to do a push --tags.



Hmm, yes. I did that.

This caused me some headaches. It seems to be that git-buildpackage 
should have kept going, or stopped with warnings. Maybe it did: I am 
still new to git.


There is definitely something wrong with the tagging (if not more): 
Here's what I get with git tag:


0.6.1
debian/0.5.11-1
upstream/0.5.11

What do you get with same command?

If you also get those same tags, then your git-import-orig is 
incomplete.


Try simply do the git-import-orig again on top of the other - that will 
cause a bit of commit noise but shouldn't mess up the packaging (but 
hopefully fix).


You can also try yourself in a different directory to do the following 
and verify that it works to build the package from that:


  gbp-clone git.debian.org:/git/pkg-multimedia/scenic


Kind regards,

 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-11 Thread Alexandre Quessy
Hello!


 Thanks! It seems to work now. It's nice that it takes care of deleting the
 .pyo files. The .pyc files are byte-compiled for Python 2.5, but it seems to
 work with 2.6 as well.

 Good.

 Not sure I read you correctly above: Do the snippet only cleanup half of the
 Python compiled files?  If you seem to reveal weaknesses in the CDBS
 snippets then do tell - so I can improve them for the benefit of all (except
 those poor souls not seeing the light of CDBS ;-) ).


Well, maybe it doesn't clean them quite... Here is an excerpt from the
list of files that are created (by python-support) when installing:

It seems like the list of Python-generated files looks different for
the midistream v/s the scenic package.

In midistream.deb:
/usr/lib/scenic/py/rtpmidi
 |engines/
   | __init__.py
   | __init__.pyc
   | __init__.pyo

In scenic.deb:
├── application.py
├── application.pyc

(there are no .po there)

There is no 2.5 or 2.6 directory, anywhere. The app seems to work
OK, though.

 Otherwise, I think this packaging stuff is going well. The upstream team
 will be ready for the 0.6.0 release for Friday, I think.

 Sounds good.  But we need not delay releasing this packaging until then:
 approval from ftpmasters may take time, so better get in in as soon as we
 feel the packaging is acceptable.  Even if you know that this upstream code
 is flawed, we can still release but (if needed) immediately file a severe
 bugreport against it to block it from entering testing.


I should import a new original tarball within a few hours. The 0.6.1
upstream release is out.

-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-11 Thread Jonas Smedegaard

On Fri, Jun 11, 2010 at 05:49:13PM -0400, Alexandre Quessy wrote:

Thanks! It seems to work now. It's nice that it takes care of 
deleting the .pyo files. The .pyc files are byte-compiled for Python 
2.5, but it seems to work with 2.6 as well.


Good.

Not sure I read you correctly above: Do the snippet only cleanup half 
of the Python compiled files?  If you seem to reveal weaknesses in 
the CDBS snippets then do tell - so I can improve them for the 
benefit of all (except those poor souls not seeing the light of CDBS 
;-) ).




Well, maybe it doesn't clean them quite... Here is an excerpt from the 
list of files that are created (by python-support) when installing:


It seems like the list of Python-generated files looks different for
the midistream v/s the scenic package.

In midistream.deb:
/usr/lib/scenic/py/rtpmidi
|engines/
  | __init__.py
  | __init__.pyc
  | __init__.pyo

In scenic.deb:
├── application.py
├── application.pyc

(there are no .po there)

There is no 2.5 or 2.6 directory, anywhere. The app seems to work
OK, though.


Hmmm. I see now that your Makefile.in for the python code uses $(libdir) 
and not $(pythondir).  This causes the code to not use standard Python 
paths, so that a) it is not possible to support multiple concurrent 
Python versions, and b) you need to explicitly tell pysupport where the 
custom files are stored so that it can properly ensure Python Policy is 
followed.


Right now the files are simply installed - not handled properly :-(


I am heading for bed now, and am busy all day tomorrow.  I will try find 
some time tomorrow night to elaborate more on this.



A few other remarks:

debian/control and debian/changelog are set executable.  They shouldn't.

Please drop the debian/.gitignore file.

Please drop the last lines of debian/gbp.conf - don't enforce a custom 
export-dir.




Kind regards,

 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-11 Thread Jonas Smedegaard

On Fri, Jun 11, 2010 at 06:32:48PM -0400, Alexandre Quessy wrote:

Hello !



I should import a new original tarball within a few hours. The 0.6.1 
upstream release is out.




It's online!


Yes, I saw your commit messages :-)



I hope everything is OK.


Hmm.  There is something weird with the pristine-tar data.

Did you use git-import-orig or something custom?

Are you sure you did not rename a bzip2 tarball or something?

Oh - maybe it is simply that you need to do a push --tags.


Kind regards,

  - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-10 Thread Jonas Smedegaard

On Wed, Jun 09, 2010 at 09:18:14PM -0400, Alexandre Quessy wrote:
Still working on this... It's not easy, but it's likely I will work 
with more free projects involving multimedia, Python and the autotools 
for a little while again. :)


Happy to hear that these challenges haven't turned you off.



2010/6/9 Jonas Smedegaard d...@jones.dk:


It should be DEB_PYTHON_MODULE_PACKAGES (not DEB_PYTHON_PACKAGES)



Thanks! It seems to work now. It's nice that it takes care of deleting 
the .pyo files. The .pyc files are byte-compiled for Python 2.5, but it 
seems to work with 2.6 as well.


Good.

Not sure I read you correctly above: Do the snippet only cleanup half of 
the Python compiled files?  If you seem to reveal weaknesses in the CDBS 
snippets then do tell - so I can improve them for the benefit of all 
(except those poor souls not seeing the light of CDBS ;-) ).



Try extend the PYTHONPATH in the check target.  Best to use make 
variable expansion using some of the variables calculated in 
/usr/share/cdbs/1/class/python-vars.mk.


If that fails to work then disable tests for now.  I find it better 
to properly use python-autotools.mk than running the tests.  But 
beware that since you know that the packaging should fail to build on 
certain architectures, then if for some reason some of those known 
failures only are discovered in the regression tests (as opposed to 
missing build-dependencies which is the more likely to happen) then 
the trick of not declaring specific supported archs but just rely on 
never succesfully built before on that arch will fail if postponing 
regression tests for later.




Well, since the unit tests mostly test the Python code, I disabled it 
for now.


I added the perl one-liner in the binary-fixup/scenic target. It 
doesn't replace the #! line in the scripts, though. Maybe I should add 
more rules or set something somewhere else?


Well, my idea was not to use it verbatim (although if relevant you can - 
and should - off course do that as well) but instead adapt it for use 
with the regression tests: I did not inspect the code, but imagined that 
in addition to adding a PYTHONPATH you might need to adjust hashbangs in 
tests as well.


If you want an example of custom PYTHONPATH export, have a look at 
radicale (one of my latest packagings).



Otherwise, I think this packaging stuff is going well. The upstream 
team will be ready for the 0.6.0 release for Friday, I think.


Sounds good.  But we need not delay releasing this packaging until then: 
approval from ftpmasters may take time, so better get in in as soon as 
we feel the packaging is acceptable.  Even if you know that this 
upstream code is flawed, we can still release but (if needed) 
immediately file a severe bugreport against it to block it from 
entering testing.



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-09 Thread Alexandre Quessy
Hello Jonas and everyone!
I greatly appreciate your help, by the way. :)

2010/6/8 Jonas Smedegaard d...@jones.dk:

 Until fixed upstream (which should be doable with autotools, I believe) we
 can probably (depending on the exact kind of problem happening, off course)
 hack the hashbang after build but before doing regression tests.

 Have a look at e.g. the radicale package for a routine to do such hack.  And
 tell me if you need help ensuring that it gets applied between build and
 tests.


That looks OK. Once I fix my current bug, I'll apply that.


 Even without providing public Python modules, I imagine it would be nice to
 be able to use your tools with a non-default Python. If irrelevant, then
 change Python version hint to be current instead of all and still use
 python-autotools.mk (as it does some magic for Python Policy even with a
 single version).


I changed my debian/rules files in order to use python-autotools.mk:

{{{
DEB_PYTHON_PRIVATE_MODULES_DIRS_scenic = /usr/lib/scenic/py
DEB_BUILDDIR = build
DEB_PYTHON_SYSTEM = pysupport
DEB_PYTHON_PACKAGES = scenic rtpmidi

include /usr/share/cdbs/1/class/python-autotools.mk
include /usr/share/cdbs/1/rules/debhelper.mk

DEB_CONFIGURE_EXTRA_FLAGS = --enable-mt
DEB_MAKE_CHECK_TARGET = check
}}}

I am not sure this is correct...

At the end of the building process, it runs the unit tests, and it
fails, since it doesn't have the path to the private Python packages
in its PYTHONPATH:

{{{
/usr/bin/make  check-TESTS
make[4]: Entering directory
`/home/aalex/src/debian/build-area/scenic-0.5.11/build/2.5/py'
[ERROR]
===
[ERROR]: 
/home/aalex/src/debian/build-area/scenic-0.5.11/./py/scenic/test/test_cameras.py
Traceback (most recent call last):
  File /usr/lib/python2.5/site-packages/twisted/trial/runner.py,
line 651, in loadByNames
things.append(self.findByName(name))
  File /usr/lib/python2.5/site-packages/twisted/trial/runner.py,
line 460, in findByName
return filenameToModule(name)
  File /usr/lib/python2.5/site-packages/twisted/trial/runner.py,
line 98, in filenameToModule
return _importFromFile(fn)
  File /usr/lib/python2.5/site-packages/twisted/trial/runner.py,
line 117, in _importFromFile
module = imp.load_source(moduleName, fn, fd)
  File 
/home/aalex/src/debian/build-area/scenic-0.5.11/./py/scenic/test/test_cameras.py,
line 7, in module
from scenic.devices import cameras
exceptions.ImportError: No module named scenic.devices
---
FAILED (errors=1)
FAIL: scenic/test/test_cameras.py
}}}


It seems like this is built in the
../build-area/scenic-0.5.11/build/2.5/py and
../build-area/scenic-0.5.11/build/2.6/py directories. Maybe I can skip
the unit tests? Maybe I can override the check target, adding these
directories to the PYTHONPATH environment variable?
-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-09 Thread Jonas Smedegaard

On Wed, Jun 09, 2010 at 02:23:51AM -0400, Alexandre Quessy wrote:

I changed my debian/rules files in order to use python-autotools.mk:

{{{
DEB_PYTHON_PRIVATE_MODULES_DIRS_scenic = /usr/lib/scenic/py
DEB_BUILDDIR = build
DEB_PYTHON_SYSTEM = pysupport
DEB_PYTHON_PACKAGES = scenic rtpmidi

include /usr/share/cdbs/1/class/python-autotools.mk
include /usr/share/cdbs/1/rules/debhelper.mk

DEB_CONFIGURE_EXTRA_FLAGS = --enable-mt
DEB_MAKE_CHECK_TARGET = check
}}}

I am not sure this is correct...


It should be DEB_PYTHON_MODULE_PACKAGES (not DEB_PYTHON_PACKAGES)

I see now that morituri has it wrong too, but accidently works anyway 
there, sorry about the confusion :-/




At the end of the building process, it runs the unit tests, and it
fails, since it doesn't have the path to the private Python packages
in its PYTHONPATH:



It seems like this is built in the
../build-area/scenic-0.5.11/build/2.5/py and
../build-area/scenic-0.5.11/build/2.6/py directories. Maybe I can skip
the unit tests? Maybe I can override the check target, adding these
directories to the PYTHONPATH environment variable?


Try extend the PYTHONPATH in the check target.  Best to use make 
variable expansion using some of the variables calculated in 
/usr/share/cdbs/1/class/python-vars.mk.


If that fails to work then disable tests for now.  I find it better to 
properly use python-autotools.mk than running the tests.  But beware 
that since you know that the packaging should fail to build on certain 
architectures, then if for some reason some of those known failures only 
are discovered in the regression tests (as opposed to missing 
build-dependencies which is the more likely to happen) then the trick of 
not declaring specific supported archs but just rely on never 
succesfully built before on that arch will fail if postponing 
regression tests for later.



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-09 Thread Alexandre Quessy
Hello!
Still working on this... It's not easy, but it's likely I will work
with more free projects involving multimedia, Python and the autotools
for a little while again. :)

2010/6/9 Jonas Smedegaard d...@jones.dk:

 It should be DEB_PYTHON_MODULE_PACKAGES (not DEB_PYTHON_PACKAGES)


Thanks! It seems to work now. It's nice that it takes care of deleting
the .pyo files. The .pyc files are byte-compiled for Python 2.5, but
it seems to work with 2.6 as well.


 Try extend the PYTHONPATH in the check target.  Best to use make variable
 expansion using some of the variables calculated in
 /usr/share/cdbs/1/class/python-vars.mk.

 If that fails to work then disable tests for now.  I find it better to
 properly use python-autotools.mk than running the tests.  But beware that
 since you know that the packaging should fail to build on certain
 architectures, then if for some reason some of those known failures only are
 discovered in the regression tests (as opposed to missing build-dependencies
 which is the more likely to happen) then the trick of not declaring specific
 supported archs but just rely on never succesfully built before on that
 arch will fail if postponing regression tests for later.


Well, since the unit tests mostly test the Python code, I disabled it for now.

I added the perl one-liner in the binary-fixup/scenic target. It
doesn't replace the #! line in the scripts, though. Maybe I should add
more rules or set something somewhere else?

Otherwise, I think this packaging stuff is going well. The upstream
team will be ready for the 0.6.0 release for Friday, I think.

-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-08 Thread Jonas Smedegaard

On Mon, Jun 07, 2010 at 12:29:55PM -0400, Alexandre Quessy wrote:

Hello Jonas and the team,
Here are some updates about the packaging of Scenic.

2010/6/3 Jonas Smedegaard d...@jones.dk:

Some additional packaging comments:

The project includes python code.  We must then follow to Debian 
Python Policy!


Since the Python code apparently is all handled with GNU autotools I 
recommend to include python-autotools.mk (instead of autotools.mk), 
add the needed hints to debian/control, and create debian/control.in 
to help track CDBS-related build-dependencies.




I tried to include python-autotools.mk on sid and the make check 
failed. To fix this would need upstream development. (I would need to 
change the python path in the executables and the tests cases)


Until fixed upstream (which should be doable with autotools, I believe) 
we can probably (depending on the exact kind of problem happening, off 
course) hack the hashbang after build but before doing regression tests.


Have a look at e.g. the radicale package for a routine to do such hack.  
And tell me if you need help ensuring that it gets applied between build 
and tests.




Scenic currently works with Python either 2.5 or 2.6. You just need to
compile the package with the same python version that is installed, and
it will run. Autotools takes care of that.


Sure - but this is Debian, not Gentoo :-) It is possible to support 
*both* 2.5 and 2.6 support at runtime without the user needing to 
recompile the package.


We provide no public module, and our project contains more C++ code 
than Python code. This is somewhat different from the morituri package.


Even without providing public Python modules, I imagine it would be nice 
to be able to use your tools with a non-default Python. If irrelevant, 
then change Python version hint to be current instead of all and 
still use python-autotools.mk (as it does some magic for Python Policy 
even with a single version).



Rigth now, I am not mandated by the Scenic team to change the build 
system, unless it's for very minor changes. Our current build system 
seems satisfying sor far. (we're running out of time on this project)


I do not ask you to change upstream code for this.  Actually, I believe 
it makes best sense that you take off your upstream hat while packaging: 
Think in how to patch and hack the upstream code instead - and then 
later on take off your packaging hat and put on your upstream hat, and 
adopt whatever relevant of those hacks and patches for next upstream 
release.




I think right now we are OK with the 3.1.1 Programs Shipping Private
Modules of the Debian Python policy.
http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs


Quite possibly.  I did not look closely...

I would still recommend to use python-autotools.mk instead of 
autotools.mk when the code contains Python!




By the way:
We should be ready to release the Scenic 0.6 version later this week. 
This release will contain big fixes, some found thanks to Debian sid!


Nice :-)


 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-07 Thread Alexandre Quessy
Hello Jonas and the team,
Here are some updates about the packaging of Scenic.

2010/6/3 Jonas Smedegaard d...@jones.dk:
 Some additional packaging comments:

 The project includes python code.  We must then follow to Debian Python
 Policy!

 Since the Python code apparently is all handled with GNU autotools I
 recommend to include python-autotools.mk (instead of autotools.mk), add the
 needed hints to debian/control, and create debian/control.in to help track
 CDBS-related build-dependencies.


I tried to include python-autotools.mk on sid and the make check failed.
To fix this would need upstream development. (I would need to change the
python path in the executables and the tests cases)

Scenic currently works with Python either 2.5 or 2.6. You just need to
compile the package with the same python version that is installed, and
it will run. Autotools takes care of that. We provide no public module,
and our project contains more C++ code than Python code. This is
somewhat different from the morituri package.

Rigth now, I am not mandated by the Scenic team to change the build
system, unless it's for very minor changes. Our current build system
seems satisfying sor far. (we're running out of time on this project)

I think right now we are OK with the 3.1.1 Programs Shipping Private
Modules of the Debian Python policy.
http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs

By the way:
We should be ready to release the Scenic 0.6 version later this week.
This release will contain big fixes, some found thanks to Debian sid!

Later,
-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-06 Thread Alexandre Quessy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Jonas and the list!

On 10-06-05 03:51 AM, Jonas Smedegaard wrote:
 Lower that package relation to suggests, and document the benefit of
 installing that suggestion (without explaining the reason it is only
 suggested, that is development-grade info IMO) in both long description
 (i.e. in debian/control) and in a debian/README.Debian file (which CDBS
 then automagically includes in the binary packages).
 

Done.

 And try post to bug#544347 again - cc'ing menucci who seem to have
 somewhat taken over maintainership and perhaps haven't noticed that old
 bug.
 

Done.

 Maybe it would be nice to also create the scenic-doc package, to
 separate the doc from the Python code. (though both are architecture:
 all)
 
 Certainly - if there is documentation of a reasonable amount then it
 should be in a separate binary package.
 

Done. :)

 
 For now, the docbook documentation (viewable with yelp) are in an
 unusual location. (/usr/share/scenic/docbook) It should probably go to
 /usr/share/gnome/help/scenic/C/scenic.xml like all gnome docs. Our
 docbook doc is made of several XML files and images, though, and we
 have two manuals...
 
 I am not very familiar with yelp, but seems to me that if the project is
 not otherwise tied specifically to Gnome and if yelp supports reading
 from non-gnome directories, then you shouldn't jump through hoops to
 install the documentation Gnome-style, but instead jump through hoops to
 get yelp to recognize it.  More importantly you should register with
 doc-base (which might be all that is needed for yelp integration too?).
 


Each .doc-base file must be for the doc of only one binary package, but
there are two manuals in Scenic! (not that I agree with that...)

Meanwhile, my current .doc-base file is installed properly, but it is
not shown by dhelp.


 Well, my excuses currently is a) I have too little time (developing and
 setting up sms service in the field for an experimental theater group),
 and b) I cannot do clean-room package compilations due to a major part
 of my laptop being readonly (heating problem caused a power outage
 during a partition resize - all data seems fine but I cannot know for
 sure, and every time I try fsck'ing that heating problem strikes again).
 
 In other words: my trouble is unrelated to the code quality :-)
 

Don't worry. Me and the Scenic team has tested it a lot since the last
few months, and on Debian unstable as well. There is no Trojan horse in
the app! - only an easter egg. I wish you to overcome these technical
problems quickly.

Here is a list of the current lintian warnings for the four packages:

- -- scenic-doc
aa...@plouf:~/src/debian/build-area$ lintian -Iv --pedantic
scenic-doc_0.5.11-1_i386.deb
N: Setting up lab in /tmp/k1R8QxDI2F ...
N: Processing 1 packages...
N: 
N: Processing binary package scenic-doc (version 0.5.11-1) ...
P: scenic-doc: no-upstream-changelog
N: Removing /tmp/k1R8QxDI2F ...

- ---  scenic
aa...@plouf:~/src/debian/build-area$ lintian -Iv --pedantic
scenic_0.5.11-1_all.deb
N: Setting up lab in /tmp/EfBpUFMNoH ...
N: Processing 1 packages...
N: 
N: Processing binary package scenic (version 0.5.11-1) ...
P: scenic: no-upstream-changelog
I: scenic: hyphen-used-as-minus-sign usr/share/man/man1/scenic.1.gz:52
I: scenic: unused-override scenic source: hyphen-used-as-minus-sign
N: Removing /tmp/EfBpUFMNoH ...

-  midistream
aa...@plouf:~/src/debian/build-area$ lintian -Iv --pedantic
midistream_0.5.11-1_all.deb
N: Setting up lab in /tmp/DSFZ66tQGW ...
N: Processing 1 packages...
N: 
N: Processing binary package midistream (version 0.5.11-1) ...
P: midistream: no-upstream-changelog
I: midistream: hyphen-used-as-minus-sign
usr/share/man/man1/midistream.1.gz:70
I: midistream: hyphen-used-as-minus-sign
usr/share/man/man1/midistream.1.gz:76
I: midistream: hyphen-used-as-minus-sign
usr/share/man/man1/midistream.1.gz:81
I: midistream: unused-override midistream source: hyphen-used-as-minus-sign
N: Removing /tmp/DSFZ66tQGW ...


 sugar-0.88

 That one also demonstrates quite well IMO how a large amount of
 package dependencies are easier to track indirectly declared in
 debian/rules, as they they can be grouped and comments added as needed.


 This is very interesting and am I looking forward to learn more about
 this. I will make some tests soon.
 
 I am happy to hear that you are interested in those features.  They are
 some of my newest additions to CDBS :-)
 

Should I get into that for the first package of Scenic? How new is it? I
am looking forward to use these advanced goodies, but I am still a
beginner at packaging... :)

Best regards,
  Alex

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMC/IdAAoJEJQ0pOgl2qx1sdIP/itJZvd5N45aYQ5sT2wtPuOn

Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-05 Thread Alexandre Quessy
Hello again!
Just a quick update: I have create the 3 .install and .manpages files.

I think it doesn't make sense to separate the libraries from at least
the milhouse command-line tool, since they are used by it or with it
only.

I am still thinking about splitting the doc from the scenic package or not.

I have filled an ITP bug for python-portmidi.

Later,
Alex

2010/6/5 Alexandre Quessy alexan...@quessy.net:
 Hello!

 2010/6/5 Alexandre Quessy alexan...@quessy.net:
 Hello again!

 I just thought about an issue that makes my package 33% unusable. :)
 The MIDI streaming feature (which would be provided by the new
 midistream package) relies on either python-portmidi or python-pygame
= 1.9.1. Those two packages are not in Debian yet!

 Actually, python-pygame 1.9.1 is in Ubuntu Lucid, but not in Debian
 Sid. I have been trying to contact the maintainer, and later answered
 to a bug about this. See
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544347 ... Maybe it
 is too late before the the release of Squeeze? There might be quite a
 few packages that depend on python-pygame. I also have an other
 package - toonloop 1.2.8 - that needs python-pygame, for its V4L2
 video input feature and the MIDI feature.

 For the MIDI feature, which is our main interest for scenic, an other
 package could provide it. It's python-portmidi. I packaged it, but did
 not contribute it yet, since the original author thought it would be
 nice to send it upstream, but it's taking time. It's not there yet:
 http://sourceforge.net/apps/trac/portmedia/browser/portmidi/trunk (4
 months with no activity) My changes to the upstream along with my
 packaging files are at http://bitbucket.org/aalex/pyportmidi/wiki/Home

 So, either we ask the maintainers of the pygame package to update it,
 or we package python-portmidi. I think that merging the pyportmidi
 code with portmidi0 would take too much time and effort for now.
 (before Squeeze) Anyways, the python-portmidi should be a separate
 package from portmidi0, so ... should fill a ITP and package it now?
 :)

 Note that the scenic application can still run, it's only that the
 MIDI features will be disabled.

 (more text below...)

 2010/6/4 Jonas Smedegaard d...@jones.dk:
 On Fri, Jun 04, 2010 at 04:57:40PM -0400, Alexandre Quessy wrote:

 Hello Jonas,

 So I have set up a Debian sid box. That will help. :)

 Good!


 2010/6/4 Jonas Smedegaard d...@jones.dk:

 On Thu, Jun 03, 2010 at 11:59:18AM -0400, Alexandre Quessy wrote:

 Done. I will have to add your license to the copyright of some of the
 Debian packaging.

 What I do is maintain packaging licensing in debian/rules.  And I
 (ideally, when not too lazy) do not add licensing info of others but 
 instead
 request them to add it themselves. ;-)


 Oops! I added your name to debian/copyright. Please edit it or remove it
 if it's not the way you like.

 No problem.  I only tried to aim at a best practice. :-)


 It does seem, however, from a quick glance, that some parts of the
 project is not arch-limited.  It might be a good idea to split 
 packaging to
 provide most possible to all archs.


 That would be nice, but it's probably going to be difficult. The
 jack-info, dc-ctl and midistream utilities could be packages separately, 
 and
 should be useful for the multimedia-loving masses. Since scenic relies on
 milhouse, they could be packaged together. Again, I am a 
 close-to-beginner
 in packaging, so I am not sure where to start, especially that the 
 current
 build process is unified and using a single autotools configure.ac 
 script.
 It would imply splitting it upstream, no?

 Packaging typically goes like this:

  1. Prepare
  2. configure
  3. build
  4. install
  5. reinstall into package area
  6. tune packaging

 Here, steps 2-4 is done by autotools, and 5-6 is done by debhelper.

 So splitting into multiple packages is (more or less) a simple matter of
 adding more binary packages in debian/control and hinting in
 debian/*.install which autotools-installed parts each of them should
 contain.


 Ok, so in this case, let's say we brake it into 3 packages:

 * scenic (contains the Python app, the documentation, the glade data,
 and the icon, etc.)
 * scenic-utils (dc-ctl, firereset, jack-info and milhouse
  executables. Man pages and some shared libraries)
 * midistream (python app and man page)


 Maybe it would be nice to also create the scenic-doc package, to
 separate the doc from the Python code. (though both are architecture:
 all)


 I put the current contents of the package, and how it could split up:
 https://svn.sat.qc.ca/trac/scenic/wiki/PackagesContents

 For now, the docbook documentation (viewable with yelp) are in an
 unusual location. (/usr/share/scenic/docbook) It should probably go to
 /usr/share/gnome/help/scenic/C/scenic.xml like all gnome docs. Our
 docbook doc is made of several XML files and images, though, and we
 have two manuals...

 The easiest way would be to create 3 *.install files. The 

Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-05 Thread Alexandre Quessy
Hello Jonas!

I am not sure how to get rid of this lintian warning:

W: scenic source: package-lacks-versioned-build-depends-on-debhelper 7
N:
N:The package doesn't declare a versioned build dependency on debhelper.
N:Recommended practice is to always declare an explicit versioned
N:dependency on debhelper equal to or greater than the compatibility level
N:used by the package, even if the versioned dependency isn't strictly
N:necessary. Having a versioned dependency also helps with backports to
N:older releases and correct builds on partially updated systems.
N:
N:Refer to the debhelper(7) manual page for details.
N:
N:Severity: minor, Certainty: certain
N:

2010/6/5 Jonas Smedegaard d...@jones.dk:
 On Sat, Jun 05, 2010 at 03:44:01AM -0400, Alexandre Quessy wrote:

 Hello again!
 Just a quick update: I have create the 3 .install and .manpages files.

 I think it doesn't make sense to separate the libraries from at least
 the milhouse command-line tool, since they are used by it or with it
 only.

 I am still thinking about splitting the doc from the scenic package or
 not.

 I have filled an ITP bug for python-portmidi.

 Great!

 Oh, and regarding python-portmidi (I forgot to comment on that earlier): It
 might be that it is too late for next release of Debian, but my
 recommendation is to lean back and work in a comfortable pace: There will be
 another release after that.  And in the meantime you (or others) can choose
 to publish unofficial or semi-official backports if you like.

 Maintaining packaging in debian, even if for whatever reason not shipping
 with the Debian distro releases, also is beneficial for derivatives like
 Ubuntu.

 So all in all, sure keep an eye on Debian release schedules, but use it only
 as guideline and encouragement, not as show-stopper :-)


Yes! Don't worry. :)


  - Jonas

 --
  * Jonas Smedegaard - idealist  Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iQIcBAEBCgAGBQJMCghAAAoJECx8MUbBoAEhb0EP/RjmPagY9y3GKD18nm2rzN1P
 WwzE2l0PdSPyZ+U+6qrSJX9vCX0+0YUhiWJCM2E8L6/RjAMYu16w9XbQkTOG3cQM
 TeocxCh7ZjW4pMn+DtflsEGjlEJHddF7+VSNLi1gCHmfTZ8dFyKHrMbSfFw5qJmk
 UKQkC4xjNB5mAhgmnsHNtbBSsMB7qcpkaPZekujo/vHQgr1TJWQOxeLw0lwSPVmM
 xLF76a3rNfZ0XyF/5caBp6F/ZqZP253IHlR/quxYGE/kiCD3F3HBJzdHGbAso09O
 sp+mTkqAlHo/IN542xmC0i1PgEDLXhnw7OLe5nvLK1Vpd8nJghMfvTX6+13YH64x
 7qr2HMx7LB3lGsKrGiXHyk/enPYK3nIY7zKeQEuMsShQ8uMxJPCpwdGD7FbS2fTJ
 GTqnvf+RnA059jLDxnyaagCIJvsS0bU2THOO34mHWeOJkXFHBEF/QC9oWgzqkbP5
 wd++KUr5CSoRY2PbBscSbeHpTRi32Z9c0DdVmdlwrABQVQThtIi5rhxbTiDoKbsk
 jeJK9jVbOre/QZuZW1labEHJZvqA6FSwJmGIplNUmeQ2iEylpk2nQlYBSg0QZM5T
 nUF8rwManROLNuKbL64hGNA1mAyV/bac2fp+j42ZYy5lSaWnUNoxxHA7e+oixuPe
 P30imUTSAY0k8m4UGIs3
 =U8Cz
 -END PGP SIGNATURE-

 ___
 pkg-multimedia-maintainers mailing list
 pkg-multimedia-maintainers@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers





-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-05 Thread Jonas Smedegaard

On Sat, Jun 05, 2010 at 01:26:00PM -0400, Alexandre Quessy wrote:

I am not sure how to get rid of this lintian warning:

W: scenic source: package-lacks-versioned-build-depends-on-debhelper 7


Normal approach: Let debian/compat contain 7 and edit debian/control 
to have a tightened build-dependency on debhelper to at least version 7.


Funky CDBS approach: Copy debian/control to debian/control.in, edit 
debian/control.in to include the magic build-dependency @cdbs@, and 
invoke DEB_MAINTAINER_MODE=1 debian/rules clean.


Then @cdbs@ gets expanded to build-dependencies resolved by CDBS, 
including the proper (unless you do something unusual requiring even 
tighter dependency) dependency on debhelper.



NB!

There's no need to quote those parts of my emails that you do not 
comment on.



Regards,

 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-05 Thread Jonas Smedegaard

On Sat, Jun 05, 2010 at 08:03:18PM +0200, Jonas Smedegaard wrote:

On Sat, Jun 05, 2010 at 01:26:00PM -0400, Alexandre Quessy wrote:

I am not sure how to get rid of this lintian warning:

W: scenic source: package-lacks-versioned-build-depends-on-debhelper 7


Normal approach: Let debian/compat contain 7 and edit debian/control 
to have a tightened build-dependency on debhelper to at least version 
7.


Funky CDBS approach: Copy debian/control to debian/control.in, edit 
debian/control.in to include the magic build-dependency @cdbs@, and 
invoke DEB_MAINTAINER_MODE=1 debian/rules clean.


Then @cdbs@ gets expanded to build-dependencies resolved by CDBS, 
including the proper (unless you do something unusual requiring even 
tighter dependency) dependency on debhelper.


Sorry for sidetracking and making it an excuse for advertising CDBS 
semi-auto-generating build-dependencies.


I had a brief look now, and as you have lowered the build-dependency, 
you should simply adjust debian/compat to match: change it to contain 
6.



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-04 Thread Jonas Smedegaard

On Thu, Jun 03, 2010 at 12:13:11PM -0400, Alexandre Quessy wrote:


2010/6/3 Jonas Smedegaard d...@jones.dk:

Some additional packaging comments:

The project includes python code.  We must then follow to Debian 
Python Policy!


Since the Python code apparently is all handled with GNU autotools I 
recommend to include python-autotools.mk (instead of autotools.mk), 
add the needed hints to debian/control, and create debian/control.in 
to help track CDBS-related build-dependencies.




I must confess that my computers are running Ubuntu Lucid ! I guess I 
could use git-pbuilder with DIST=sid. I am shopping for a nice 
virtualization tool to create a sid environment...


The problem is that python-autotools.mk is not provided by cdbs on 
Ubuntu Lucid right now. Maybe I could compile and install it from the 
sources?


When packaging for Debian, you really should be using Debian unstable, 
as that is the environment that your packaging is aimed at.


No, I do not recommend that you backport the specific pieces needed to 
satisfy build-dependencies, as you then do not know if you are 
triggering some strange hidden bug in your particular combination of 
packages from then different sources!  Ubuntu Lucid is tested against 
Ubuntu Lucid, and Debian Sid is tested against Debian Sid.  Feel free to 
mix'n'match all you like SOMEWHERE ELSE, but make sure to use a standard 
system for building packages!


You might be interested in the scripts that I personally use to 
bootstrap build environments.  I use same routines also for backporting, 
and would expect it to work just as well on Ubuntu.  If interested then 
here's a minimal howto:


  # cd /usr/local
  # mv bin bin.off
  # git clone git://source.jones.dk/bin
  $ localcowbuilder-create sid
  $ cd $pkg
  $ localcowdebuild sid

Possibly it's a too minimal HOWTO - try look at the shell code itself - 
and just ignore all those scripts that are not related to package 
compilation :-)



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-04 Thread Jonas Smedegaard

On Thu, Jun 03, 2010 at 11:59:18AM -0400, Alexandre Quessy wrote:

Done. I will have to add your license to the copyright of some of the 
Debian packaging.


What I do is maintain packaging licensing in debian/rules.  And I 
(ideally, when not too lazy) do not add licensing info of others but 
instead request them to add it themselves. ;-)




Actually, git-buildpackage doesn't work anymore with this. I removed
it locally... I am missing some point on how to use pristine-tar. It
needs the upstream tarball in the parent directory, or so... working
on this.


No, the whole point of pristine-tar is that the Git is fully 
self-contained: You need not put a tarball anywhere, git-buildpackage 
regenerates it as needed.


What fails now for you is that you simply grabbed by gbp.conf file 
wich contained not only what you needed but also a hint to use bzip2 
compressed tarballs.  The tarball actually contained in the Git 
currently is a good old gzip-compressed one so is ignored when you tell 
git-buildpackage to instead use bzip2 :-P



It does seem, however, from a quick glance, that some parts of the 
project is not arch-limited.  It might be a good idea to split 
packaging to provide most possible to all archs.




That would be nice, but it's probably going to be difficult. The
jack-info, dc-ctl and midistream utilities could be packages
separately, and should be useful for the multimedia-loving masses.
Since scenic relies on milhouse, they could be packaged together.
Again, I am a close-to-beginner in packaging, so I am not sure where
to start, especially that the current build process is unified and
using a single autotools configure.ac script. It would imply splitting
it upstream, no?


Packaging typically goes like this:

 1. Prepare
 2. configure
 3. build
 4. install
 5. reinstall into package area
 6. tune packaging

Here, steps 2-4 is done by autotools, and 5-6 is done by debhelper.

So splitting into multiple packages is (more or less) a simple matter of 
adding more binary packages in debian/control and hinting in 
debian/*.install which autotools-installed parts each of them should 
contain.




Either json or simplejson is used upstream.  Are you aware that 
those implementations are not fully interchangeable (one of them - 
I forgot which - do not follow JSON specs!), and they might be slow 
too?  The Sugar project switched to python-cjson for these reasons.


Wouldn't it be simpler to depend on python (= 2.6) | python-simplejson 
? If not, I'll try with cjson.


Sure, if it works.

What I warned about is that it those JSON implementations might not 
behave equally.  And that I do not remember the details, but know for 
sure that the Sugar developers ended up switching to cjson and only 
that.



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-04 Thread Alexandre Quessy
Hello Jonas,

So I have set up a Debian sid box. That will help. :)

2010/6/4 Jonas Smedegaard d...@jones.dk:
 On Thu, Jun 03, 2010 at 11:59:18AM -0400, Alexandre Quessy wrote:

 Done. I will have to add your license to the copyright of some of the
 Debian packaging.

 What I do is maintain packaging licensing in debian/rules.  And I (ideally,
 when not too lazy) do not add licensing info of others but instead request
 them to add it themselves. ;-)


Oops! I added your name to debian/copyright. Please edit it or remove
it if it's not the way you like.


 Actually, git-buildpackage doesn't work anymore with this. I removed
 it locally... I am missing some point on how to use pristine-tar. It
 needs the upstream tarball in the parent directory, or so... working
 on this.

 No, the whole point of pristine-tar is that the Git is fully self-contained:
 You need not put a tarball anywhere, git-buildpackage regenerates it as
 needed.

 What fails now for you is that you simply grabbed by gbp.conf file wich
 contained not only what you needed but also a hint to use bzip2 compressed
 tarballs.  The tarball actually contained in the Git currently is a good old
 gzip-compressed one so is ignored when you tell git-buildpackage to instead
 use bzip2 :-P


I had just figured that out. :)


 It does seem, however, from a quick glance, that some parts of the
 project is not arch-limited.  It might be a good idea to split packaging to
 provide most possible to all archs.


 That would be nice, but it's probably going to be difficult. The
 jack-info, dc-ctl and midistream utilities could be packages
 separately, and should be useful for the multimedia-loving masses.
 Since scenic relies on milhouse, they could be packaged together.
 Again, I am a close-to-beginner in packaging, so I am not sure where
 to start, especially that the current build process is unified and
 using a single autotools configure.ac script. It would imply splitting
 it upstream, no?

 Packaging typically goes like this:

  1. Prepare
  2. configure
  3. build
  4. install
  5. reinstall into package area
  6. tune packaging

 Here, steps 2-4 is done by autotools, and 5-6 is done by debhelper.

 So splitting into multiple packages is (more or less) a simple matter of
 adding more binary packages in debian/control and hinting in
 debian/*.install which autotools-installed parts each of them should
 contain.


Ok, so in this case, let's say we brake it into 3 packages:

 * scenic (contains the Python app, the documentation, the glade data,
and the icon, etc.)
 * scenic-utils (dc-ctl, firereset, jack-info and milhouse
executables. Man pages and some shared libraries)
 * midistream (python app and man page)

The easiest way would be to create 3 *.install files. The quick
benefit to this, is that we will have a few packages that are
architecture-independant, namely the two Python-only binary packages:
scenic and midistream. That totally makes sense. I am looking for an
example of doing this... (which uses cdbs and the autotools, if
possible) Got any?


 Either json or simplejson is used upstream.  Are you aware that those
 implementations are not fully interchangeable (one of them - I forgot 
 which
 - do not follow JSON specs!), and they might be slow too?  The Sugar 
 project
 switched to python-cjson for these reasons.

 Wouldn't it be simpler to depend on python (= 2.6) | python-simplejson ?
 If not, I'll try with cjson.

 Sure, if it works.


I just tried and it seems OK. I've pushed it to alioth.

 What I warned about is that it those JSON implementations might not behave
 equally.  And that I do not remember the details, but know for sure that the
 Sugar developers ended up switching to cjson and only that.


  - Jonas

 --
  * Jonas Smedegaard - idealist  Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
 ___
 pkg-multimedia-maintainers mailing list
 pkg-multimedia-maintainers@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers




See ya,
-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-04 Thread Jonas Smedegaard

On Fri, Jun 04, 2010 at 04:57:40PM -0400, Alexandre Quessy wrote:

Hello Jonas,

So I have set up a Debian sid box. That will help. :)


Good!



2010/6/4 Jonas Smedegaard d...@jones.dk:

On Thu, Jun 03, 2010 at 11:59:18AM -0400, Alexandre Quessy wrote:

Done. I will have to add your license to the copyright of some of 
the Debian packaging.


What I do is maintain packaging licensing in debian/rules.  And I 
(ideally, when not too lazy) do not add licensing info of others but 
instead request them to add it themselves. ;-)




Oops! I added your name to debian/copyright. Please edit it or remove 
it if it's not the way you like.


No problem.  I only tried to aim at a best practice. :-)


It does seem, however, from a quick glance, that some parts of the 
project is not arch-limited.  It might be a good idea to split 
packaging to provide most possible to all archs.




That would be nice, but it's probably going to be difficult. The 
jack-info, dc-ctl and midistream utilities could be packages 
separately, and should be useful for the multimedia-loving masses. 
Since scenic relies on milhouse, they could be packaged together. 
Again, I am a close-to-beginner in packaging, so I am not sure where 
to start, especially that the current build process is unified and 
using a single autotools configure.ac script. It would imply 
splitting it upstream, no?


Packaging typically goes like this:

 1. Prepare
 2. configure
 3. build
 4. install
 5. reinstall into package area
 6. tune packaging

Here, steps 2-4 is done by autotools, and 5-6 is done by debhelper.

So splitting into multiple packages is (more or less) a simple matter 
of adding more binary packages in debian/control and hinting in 
debian/*.install which autotools-installed parts each of them should 
contain.




Ok, so in this case, let's say we brake it into 3 packages:

* scenic (contains the Python app, the documentation, the glade data, 
  and the icon, etc.)

* scenic-utils (dc-ctl, firereset, jack-info and milhouse
  executables. Man pages and some shared libraries)
* midistream (python app and man page)

The easiest way would be to create 3 *.install files. The quick
benefit to this, is that we will have a few packages that are
architecture-independant, namely the two Python-only binary packages:
scenic and midistream. That totally makes sense.


Yes, that seems sensible (from reading it alone - I must admit that I 
have not yet tried compiling the project and looking at the results).



I am looking for an example of doing this... (which uses cdbs and the 
autotools, if possible) Got any?


sugar-0.88

That one also demonstrates quite well IMO how a large amount of package 
dependencies are easier to track indirectly declared in debian/rules, as 
they they can be grouped and comments added as needed.



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-04 Thread Alexandre Quessy
Hello!

2010/6/5 Alexandre Quessy alexan...@quessy.net:
 Hello again!

 I just thought about an issue that makes my package 33% unusable. :)
 The MIDI streaming feature (which would be provided by the new
 midistream package) relies on either python-portmidi or python-pygame
= 1.9.1. Those two packages are not in Debian yet!

 Actually, python-pygame 1.9.1 is in Ubuntu Lucid, but not in Debian
 Sid. I have been trying to contact the maintainer, and later answered
 to a bug about this. See
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544347 ... Maybe it
 is too late before the the release of Squeeze? There might be quite a
 few packages that depend on python-pygame. I also have an other
 package - toonloop 1.2.8 - that needs python-pygame, for its V4L2
 video input feature and the MIDI feature.

 For the MIDI feature, which is our main interest for scenic, an other
 package could provide it. It's python-portmidi. I packaged it, but did
 not contribute it yet, since the original author thought it would be
 nice to send it upstream, but it's taking time. It's not there yet:
 http://sourceforge.net/apps/trac/portmedia/browser/portmidi/trunk (4
 months with no activity) My changes to the upstream along with my
 packaging files are at http://bitbucket.org/aalex/pyportmidi/wiki/Home

 So, either we ask the maintainers of the pygame package to update it,
 or we package python-portmidi. I think that merging the pyportmidi
 code with portmidi0 would take too much time and effort for now.
 (before Squeeze) Anyways, the python-portmidi should be a separate
 package from portmidi0, so ... should fill a ITP and package it now?
 :)

 Note that the scenic application can still run, it's only that the
 MIDI features will be disabled.

 (more text below...)

 2010/6/4 Jonas Smedegaard d...@jones.dk:
 On Fri, Jun 04, 2010 at 04:57:40PM -0400, Alexandre Quessy wrote:

 Hello Jonas,

 So I have set up a Debian sid box. That will help. :)

 Good!


 2010/6/4 Jonas Smedegaard d...@jones.dk:

 On Thu, Jun 03, 2010 at 11:59:18AM -0400, Alexandre Quessy wrote:

 Done. I will have to add your license to the copyright of some of the
 Debian packaging.

 What I do is maintain packaging licensing in debian/rules.  And I
 (ideally, when not too lazy) do not add licensing info of others but 
 instead
 request them to add it themselves. ;-)


 Oops! I added your name to debian/copyright. Please edit it or remove it
 if it's not the way you like.

 No problem.  I only tried to aim at a best practice. :-)


 It does seem, however, from a quick glance, that some parts of the
 project is not arch-limited.  It might be a good idea to split packaging 
 to
 provide most possible to all archs.


 That would be nice, but it's probably going to be difficult. The
 jack-info, dc-ctl and midistream utilities could be packages separately, 
 and
 should be useful for the multimedia-loving masses. Since scenic relies on
 milhouse, they could be packaged together. Again, I am a close-to-beginner
 in packaging, so I am not sure where to start, especially that the current
 build process is unified and using a single autotools configure.ac script.
 It would imply splitting it upstream, no?

 Packaging typically goes like this:

  1. Prepare
  2. configure
  3. build
  4. install
  5. reinstall into package area
  6. tune packaging

 Here, steps 2-4 is done by autotools, and 5-6 is done by debhelper.

 So splitting into multiple packages is (more or less) a simple matter of
 adding more binary packages in debian/control and hinting in
 debian/*.install which autotools-installed parts each of them should
 contain.


 Ok, so in this case, let's say we brake it into 3 packages:

 * scenic (contains the Python app, the documentation, the glade data,
 and the icon, etc.)
 * scenic-utils (dc-ctl, firereset, jack-info and milhouse
  executables. Man pages and some shared libraries)
 * midistream (python app and man page)


 Maybe it would be nice to also create the scenic-doc package, to
 separate the doc from the Python code. (though both are architecture:
 all)


I put the current contents of the package, and how it could split up:
https://svn.sat.qc.ca/trac/scenic/wiki/PackagesContents

 For now, the docbook documentation (viewable with yelp) are in an
 unusual location. (/usr/share/scenic/docbook) It should probably go to
 /usr/share/gnome/help/scenic/C/scenic.xml like all gnome docs. Our
 docbook doc is made of several XML files and images, though, and we
 have two manuals...

 The easiest way would be to create 3 *.install files. The quick
 benefit to this, is that we will have a few packages that are
 architecture-independant, namely the two Python-only binary packages:
 scenic and midistream. That totally makes sense.

 Yes, that seems sensible (from reading it alone - I must admit that I have
 not yet tried compiling the project and looking at the results).


 It's rather complex to actually use it to its fullest - it needs two
 computers - but the 

Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-03 Thread Jonas Smedegaard

Some additional packaging comments:

The project includes python code.  We must then follow to Debian Python 
Policy!


Since the Python code apparently is all handled with GNU autotools I 
recommend to include python-autotools.mk (instead of autotools.mk), add 
the needed hints to debian/control, and create debian/control.in to help 
track CDBS-related build-dependencies.


Again, see morituri for an example of this.

You might find debian/README.source of morituri a useful read - and if 
you like it then feel free to adopt if, off course :-)



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-03 Thread Alexandre Quessy
Hello!
Some updates, since I'm currently working on this...

I have to fix the make clean upstream. There are still *.pyc files not
cleaned. (fixed) Some files are removed from the dist target. (It will
be effective in the next upstream release, which is 0.5.12)
There are _trial_temp and .libs directories which will be cleaned
up as well.

2010/6/3 Jonas Smedegaard d...@jones.dk:
 On Wed, Jun 02, 2010 at 10:52:23PM -0400, Alexandre Quessy wrote:

 2010/6/2 Jonas Smedegaard d...@jones.dk:

 After a nice meal I now have some comments on your packaging:

 First of all: Please package using git-buildpackage and upload to the
 pkg-multimedia repository - more info here:
 http://wiki.debian.org/DebianMultimedia/DevelopPackaging


 Done. Everything seems to be OK, as far as I know.

 Looks ok to me too.  You should probably add a debian/gbp.conf file to
 ensure pristine-tar is used in the future too.  See e.g. morituri package
 for an example of that.


Done. I will have to add your license to the copyright of some of the
Debian packaging.
Actually, git-buildpackage doesn't work anymore with this. I removed
it locally... I am missing some point on how to use pristine-tar. It
needs the upstream tarball in the parent directory, or so... working
on this.


 (it is not that morituri is the most excellent package out there, I just
 picked one that is tiny and has little unusual stuff - I generally seek to
 evolve all packagings that I am invovled in into examples for others to
 reuse, so tell me if you want an example of some specific quirk and I'll try
 find a package demonstrating it!).


[removed some replied-to text...]


 On a related note, I see that you bumped to debhelper 7.  Beware that this
 might provide no benefits over debhelper 6, and may make it more difficult
 to backport, if you happen to care about that.


I decreased it to version 6. I am not sure that backporting will ever
be possible, since Scenic (milhouse) relies on recent versions of
GStreamer plugins. We'll see. :)


 The binary package is arch: any, but the configure.ac checks for
 linux/videodev2.h which I suspect means that the package will only
 succesfully compile on Linux architectures.  If correct, then the best would
 probably be to fix it upstream to avoid Linux-specific parts when on
 non-linux archs, or alternatively to tighten to package only on Linux archs.


 Well, for now, Scenic relies heavily on the GNU/Linux kernel. (For the
 dc1394 module and V4L2) Should we put something like uclinux-*?

 I don't know what you mean by uclinux-*.

`dpkg-architecture -L` lists me a whole lot of uclinux-something:
uclinux-armel
uclinux-i386
uclinux-ia64
uclinux-alpha
uclinux-amd64
uclinux-armeb
uclinux-arm
uclinux-avr32
uclinux-hppa
uclinux-m32r
uclinux-m68k
uclinux-mips
uclinux-mipsel
uclinux-powerpc
uclinux-ppc64
uclinux-s390
uclinux-s390x
uclinux-sh3
uclinux-sh3eb
uclinux-sh4
uclinux-sh4eb
uclinux-sparc
...that might be the list I am looking for.


 What is common to do is to replace any in Architecture: any with all
 known-to-work Debian targets that is supported by the project.

 I dislike such hardcoded lists, however, and prefer to instead
 semi-automatically resolve it, either through dependent package (see e.g.
 calf for an example of that) or using type-handling (can't find an example
 of that right now).

 It does seem, however, from a quick glance, that some parts of the project
 is not arch-limited.  It might be a good idea to split packaging to provide
 most possible to all archs.


That would be nice, but it's probably going to be difficult. The
jack-info, dc-ctl and midistream utilities could be packages
separately, and should be useful for the multimedia-loving masses.
Since scenic relies on milhouse, they could be packaged together.
Again, I am a close-to-beginner in packaging, so I am not sure where
to start, especially that the current build process is unified and
using a single autotools configure.ac script. It would imply splitting
it upstream, no?


 Either json or simplejson is used upstream.  Are you aware that those
 implementations are not fully interchangeable (one of them - I forgot which
 - do not follow JSON specs!), and they might be slow too?  The Sugar project
 switched to python-cjson for these reasons.


 Ok. Being the main upstream author for the Python in Scenic, I will
 try check if switching to python-cjson is seemless. Note that in the
 Python code, I check if the json module is the same as the former
 simplejson module. Simplejson is part of the standard Python library
 as json since Python 2.6. I could depend on either python = 2.6 or
 python-simplejson. See http://docs.python.org/library/json.html ... I
 don't know why Python named the module the same name as the former
 json module but replaced it by a new - different one.

 I am no expert in the area.  Tell me if you would find it useful that I try
 dig out the relevant ML thread at the Sugar project.


Wouldn't it be simpler to depend on 

Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-03 Thread Alexandre Quessy
Hello again. :)

2010/6/3 Jonas Smedegaard d...@jones.dk:
 Some additional packaging comments:

 The project includes python code.  We must then follow to Debian Python
 Policy!

 Since the Python code apparently is all handled with GNU autotools I
 recommend to include python-autotools.mk (instead of autotools.mk), add the
 needed hints to debian/control, and create debian/control.in to help track
 CDBS-related build-dependencies.


I must confess that my computers are running Ubuntu Lucid ! I guess I
could use git-pbuilder with DIST=sid. I am shopping for a nice
virtualization tool to create a sid environment...

The problem is that python-autotools.mk is not provided by cdbs on
Ubuntu Lucid right now. Maybe I could compile and install it from the
sources?

 Again, see morituri for an example of this.

 You might find debian/README.source of morituri a useful read - and if you
 like it then feel free to adopt if, off course :-)


  - Jonas

 --
  * Jonas Smedegaard - idealist  Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iQIcBAEBCgAGBQJMB4dyAAoJECx8MUbBoAEhnSwP/iQ7V1/uqi4eYJWSAUQipDZh
 RVO0VxxIsH3KlF+0U/RlqU1d0X6/bezBVHEyw5Akt9EXzfIuz8Ukv8jltQRha0Qh
 IgW/uBCl3GjuLwIFvisjSsVsTYki/SPQJKxmMFHTCiHZa2r4qEgJHSemZ0Y7dDng
 TKeKQ/1mnYrOtowY0iGCN7DnXS74arxVZEGqaH1jhaty+8DaSjbVr1ngz59W82I2
 qcRc2OjphhSDxR0x1sDKFo0ljgde49DI1So5GfK7RoUsM/8ke4AgVCm4eO0pkIEA
 +PdR2p1ues4NOVgkaM8COT6dgIvweb8gseoKF45t98MQ3BkTMI27Me3WsN6Sr+1o
 2UW9JDP5bOe9FuNhw3pC5FLBDU6dtoYECNIBriigC6pmqQszDxoQhXCd+mY93uqq
 /VGdFV3wVdsOBf5ar5r3a4Zfe+64QLq8aN9KVJdav8i+d9GeGyyLFAnP6tlcoENg
 XXTbogPSLwskLomAZGmB9APkLV2MT4ApvPKbehL0EUZ3uFU2nbsek9rLPKxwXfdO
 ia04MAUcJtD1qHbdM4xrYYeqhc6/XFlmTrljv0jaFHfyT91/bTkLbCPYFvIA4eSL
 a4Z1ZFuZW96aGfn2HX/h2V7nNfWyi8ToIPRZmpqW+I0K+qdHZ9A+5ixa7eigm7ii
 c0CVMhwaSfJNhWqWJDxP
 =Vb8Q
 -END PGP SIGNATURE-

 ___
 pkg-multimedia-maintainers mailing list
 pkg-multimedia-maintainers@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers





-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-03 Thread Felipe Sateler
On Thu, Jun 3, 2010 at 11:59, Alexandre Quessy alexan...@quessy.net wrote:


 The binary package is arch: any, but the configure.ac checks for
 linux/videodev2.h which I suspect means that the package will only
 succesfully compile on Linux architectures.  If correct, then the best 
 would
 probably be to fix it upstream to avoid Linux-specific parts when on
 non-linux archs, or alternatively to tighten to package only on Linux 
 archs.


 Well, for now, Scenic relies heavily on the GNU/Linux kernel. (For the
 dc1394 module and V4L2) Should we put something like uclinux-*?

 I don't know what you mean by uclinux-*.

 `dpkg-architecture -L` lists me a whole lot of uclinux-something:
 uclinux-armel
 uclinux-i386
 uclinux-ia64
 uclinux-alpha
 uclinux-amd64
 uclinux-armeb
 uclinux-arm
 uclinux-avr32
 uclinux-hppa
 uclinux-m32r
 uclinux-m68k
 uclinux-mips
 uclinux-mipsel
 uclinux-powerpc
 uclinux-ppc64
 uclinux-s390
 uclinux-s390x
 uclinux-sh3
 uclinux-sh3eb
 uclinux-sh4
 uclinux-sh4eb
 uclinux-sparc
 ...that might be the list I am looking for.

No, thats not it. That is probably linux + uClibc, which is not what
you are after. You could use linux-any in the Architecture field, but
I'm not sure if that really works in practice (last time I heard about
this the buildds did not work correctly).

Anyway, since this is a new package, you might just want to put
architecture:any and let it fail on unsupported archs.

-- 

Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-02 Thread Jonas Smedegaard

Hi Alexandre,

On Wed, Jun 02, 2010 at 10:42:27AM -0400, Alexandre Quessy wrote:

As a new member of this team, I would like to find a sponsor for the 
scenic package.


There is sponsoring, and there is team maintainance.  They are two 
different styles of working together.


With sponsoring you maintain your package alone, and then hand it over 
to someone with upload rights who sign your package (after inspecting 
its sanity and perhaps requesting you to improve some things or doing 
some improvements themselves).


With team maintainance you work on a package - maybe alone, maybe with 
others in the team, and when you/they feel the package is ready for 
release you shout here at the list for someone with upload rights to 
finalize and upload.



The difference is not only in concrete working style, but also in who 
takes responsibility towards the users in the wuality assurance of the 
package: A team or a single developer.



Since you mention that you are part of our team (sorry - I did not know, 
I am lousy at keeping track of such things), I guess what you really 
want is not sponsoring at all, but just some fellow team member to 
help finalize and upload :-)



I use cdbs, but I am ready to switch to debhelper 7 if we fix some 
issues I had with it. (we need to build it with --enable-mt)


What is your own preference here?

Do you want to continue using CDBS if that is acceptable, or do you not 
like CDBS and prefer yourself to get rid of it?


If the first, then I will be happy to work with you - I only use CDBS 
and is quite happy with it.  If the latter then I will rather not spend 
time on this, but leave it to others in this team to work with you :-)



Kind regards,

 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-02 Thread Jonas Smedegaard

On Wed, Jun 02, 2010 at 01:03:23PM -0400, Alexandre Quessy wrote:

Thanks for the precious informations. I rather work through a team and 
build long-term cooperation, rather than though sponsors. I can work 
with the Python-app team and the pkg-multimedia team.


Excellent!



2010/6/2 Jonas Smedegaard d...@jones.dk:


I use cdbs, but I am ready to switch to debhelper 7 if we fix some 
issues I had with it. (we need to build it with --enable-mt)


What is your own preference here?

Do you want to continue using CDBS if that is acceptable, or do you 
not like CDBS and prefer yourself to get rid of it?


Well, I would rather stick with CDBS for now, since it works for this
package. I tried to switch to debhelper 7, but it didn't work at the
first try.


Great!


I am dead hungry (and in Italy this week, so looking forward to the food 
quality here in Torino!), but will try have a look at your packaging 
later tonight, and get back yo you.



If the first, then I will be happy to work with you - I only use CDBS 
and is quite happy with it.  If the latter then I will rather not 
spend time on this, but leave it to others in this team to work with 
you :-)




Wow! I am very impressed by the list of packages you are working on. I 
would be very happy to work with you for this package! My long-time 
will is to become a DD, mostly for multimedia.


He he - year, the list grows... :-)

I am very happy to hear that you are aiming long-term for becoming a 
developer.  I will do my best to help you with that!



For this scenic package, I will release the 0.5.11 tag in a few hours 
today. (I'm in Montreal, so my time zone is -0400) My packaging is 
pretty much ready and our big app is very stable right now. I think 
there is not much work left to do.


You don't know me - I am pretty sure I will find some nitpicking to do 
:-P




You can find me on the #debian-multimedia IRC channel, if you want.


I try to avoid realtime chat, as it is so very fun and thus steal too 
much of my time :-/



 - Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-02 Thread Alexandre Quessy
Hello Jonas and the team!
I just released the 0.5.11 tag of Scenic. It contains a few bugfixes,
and I've worked on the packaging since 0.5.10-2. My first packaging
for it is on 
http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=scenic
and is, of course, 0.5.11-1.

It builds successfully on my pbuilder, and appears to be lintian
clean, except for man pages errors when running it in a pedantic way,
and some other errors:
 * spelling-error-in-manpage
 * hyphen-used-as-minus-sign
 * postinst-has-useless-call-to-ldconfig
 * postrm-has-useless-call-to-ldconfig

Scenic is hard to test, though, because it needs two computers and
ideally some audio/video hardware. JACK needs to be running if one
wants to stream audio.

a

2010/6/2 Jonas Smedegaard d...@jones.dk:
 On Wed, Jun 02, 2010 at 01:03:23PM -0400, Alexandre Quessy wrote:

 Thanks for the precious informations. I rather work through a team and
 build long-term cooperation, rather than though sponsors. I can work with
 the Python-app team and the pkg-multimedia team.

 Excellent!


 2010/6/2 Jonas Smedegaard d...@jones.dk:

 I use cdbs, but I am ready to switch to debhelper 7 if we fix some
 issues I had with it. (we need to build it with --enable-mt)

 What is your own preference here?

 Do you want to continue using CDBS if that is acceptable, or do you not
 like CDBS and prefer yourself to get rid of it?

 Well, I would rather stick with CDBS for now, since it works for this
 package. I tried to switch to debhelper 7, but it didn't work at the
 first try.

 Great!


 I am dead hungry (and in Italy this week, so looking forward to the food
 quality here in Torino!), but will try have a look at your packaging later
 tonight, and get back yo you.


 If the first, then I will be happy to work with you - I only use CDBS and
 is quite happy with it.  If the latter then I will rather not spend time on
 this, but leave it to others in this team to work with you :-)


 Wow! I am very impressed by the list of packages you are working on. I
 would be very happy to work with you for this package! My long-time will is
 to become a DD, mostly for multimedia.

 He he - year, the list grows... :-)

 I am very happy to hear that you are aiming long-term for becoming a
 developer.  I will do my best to help you with that!


 For this scenic package, I will release the 0.5.11 tag in a few hours
 today. (I'm in Montreal, so my time zone is -0400) My packaging is pretty
 much ready and our big app is very stable right now. I think there is not
 much work left to do.

 You don't know me - I am pretty sure I will find some nitpicking to do :-P


 You can find me on the #debian-multimedia IRC channel, if you want.

 I try to avoid realtime chat, as it is so very fun and thus steal too much
 of my time :-/


  - Jonas

 --
  * Jonas Smedegaard - idealist  Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iQIcBAEBCgAGBQJMBp1UAAoJECx8MUbBoAEhHnAP/2vANbtCWN28VeSeNb+H3niy
 sowlaZpegzT1U+LginjxrrEvrEBnYAXiAi1wDywRoUk46ehu2e5oU2hoG2bGVn17
 qpsg5m943UManhINaJEKfHoV/SN2G5vmbfG95RSQPClorRJQ3wwuFf/eU7b0Eibp
 /yDusJSMMe8nEIzZyLdpnpWGWUqopllaTkfahGJNSv4a0X/AcAN5AGbMcJwuxGHs
 ZGtf1wQ77Lj14rtqJBgFu11XFxXyrq/6jFcOdZ6GIzkPmMEZ8g7hBB20/edAtDm1
 3X9N26q3g4hh3MJFX2bLLlXKhXHaXjOOf7AbKQyfod/AjlhcA7uUUeMIkf2NW39n
 I/Qv9Lnr9IrFBpRpSUxSo4TmniU2Zbh1CiYXA+8SfW7CQDLB2g6IliHh4F5WiGea
 lZhzMn1wmPNn5tkLrHdB7Sc0WFgO835oAD+gfGey9GIvr1AyLaC7QnpWzVkYSMwm
 Pmg/MDp3twiZhGayWBCE6Qv0BAl/obW/ldbkXCVTVJdReOBcpuwAbgqDojzT5VXy
 y6ifr3R+Elcr5Bv5QFpjA/PxHIsTZTTV3JqjjKPgGKIgipixDb2aBBbU1LfjwKps
 IR786tvRgkVu28MSOQTdrXtLT8zkGokqqzZTJWSDvaUOr8HEIvL1oDCPNbwni3bp
 bdvGZ/smwc1+UEZI2jSW
 =bVcc
 -END PGP SIGNATURE-

 ___
 pkg-multimedia-maintainers mailing list
 pkg-multimedia-maintainers@lists.alioth.debian.org
 http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers





-- 
Alexandre Quessy
http://alexandre.quessy.net/

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

2010-06-02 Thread Jonas Smedegaard

After a nice meal I now have some comments on your packaging:

First of all: Please package using git-buildpackage and upload to the 
pkg-multimedia repository - more info here: 
http://wiki.debian.org/DebianMultimedia/DevelopPackaging


When you have switched to Git, then add Vcs-Git and Vcs-Browser stanzas 
to the control file.


Set the Multimedia team as Maintainer and yourself as Uploader (yeah, 
technically you cannot upload, but in this team we use that field as a 
hint of whom is mainly working on the package).


Long descriptions should be line-wrapped at 72 chars.

Avoid stray spaces at end of lines (noticed in long description, but 
should be avoided everywhere).


Your Suggests: seem odd: do the project really make direct use of those 
tools?  If it is just that you happen to find those tools nice to have 
installed on same hosts as you use this project, then I suspect they 
should simply be dropped, or alternatively (but I find it a bad style) 
in a separate metapackage depending on the actual project package and 
those add-ons that you find relevant to have installed together.


There are no packages in Debian named linux-rt or linux-headers-rt.  
Please package for Debian, and then secondary - if needed - adjust for 
derived distributions like Ubuntu using alternative Git branches.


You have some commented out dependency lines in the control file.  It 
works, but is bad style IMO.  When using CDBS, you can instead declare 
dependencies in the rules file, allowing both commenting out, grouping 
of relations with added explanatory comments, and conditional relations 
(e.g. arch-dependent or when compiling with a certain build flag set).  
See e.g. the morituri package for an example of this.


Please use recursively expanded variables in the rules file whenever 
possible.  That is, instead of := use = which mean the content gets 
resolved when used rather than when read by make.  In most cases there 
are no differences but in some cases there are, which can cause 
surprises if unaware of the differences.


It is bad style to invoke dh_install again (in addition to the included 
debhelper.mk snippet).  Instead either add a debian/scenic.install 
file, or set DEB_DH_INSTALL_ARGS.


Are you sure you need to build-depend on bash-completion?

The binary package is arch: any, but the configure.ac checks for 
linux/videodev2.h which I suspect means that the package will only 
succesfully compile on Linux architectures.  If correct, then the best 
would probably be to fix it upstream to avoid Linux-specific parts when 
on non-linux archs, or alternatively to tighten to package only on Linux 
archs.


Either json or simplejson is used upstream.  Are you aware that those 
implementations are not fully interchangeable (one of them - I forgot 
which - do not follow JSON specs!), and they might be slow too?  The 
Sugar project switched to python-cjson for these reasons.


It seems some subprojects provide regression tests.  If usable then 
please enable them.  Most elegant approach - if workable - is to set 
DEB_MAKE_CHECK_TARGET = check .


Have a look at e.g. morituri package for some modern CDBS enhancements - 
like upstream tarball processing, and copyright and licensing tracking.



Please don't hesitate to ask if any of this is not clear to understand 
for you.



Kind regards,

- Jonas

--
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers