Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
-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
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
-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
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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
