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 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
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 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/ 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
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/ 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 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/ 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 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 18:06:06 (CEST), Jonas Smedegaard wrote: >>really depends on how the package uses them. In general, putting them >>into /usr/lib/$package/ should do it, but it really depends on how the >>package uses them. are they used as plugins like in xine, vlc? or are >>they convenience shared libraries, like e.g. in openoffice? >> >>where do upstream's installation scripts install them? > > As quoted above, it is normal shared libraries which upstream simply > consider immature for public use. that's fair. > Personally I suspect that as such we really should treat them as normal > public shared libraries anyway for Debian packaging well, I suspect upstream considers them immature and instable for a reason, no? > (as I suspect we might run into similar packaging upgrade problems no > matter how stable upstram consider the files), but I might be unaware > of other acceptable approaches. > > Upstream install the files below /usr/lib/scenic/ the obvious approach: just leave them there and be done with it. what problem do you try to solve? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
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/ 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 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 : 2010/8/15 Alexandre Quessy : 2010/8/15 Jonas Smedegaard : 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 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/ 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 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 : >>> 2010/8/15 Alexandre Quessy : 2010/8/15 Jonas Smedegaard : > 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 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/ 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 Mon, Aug 30, 2010 at 10:26:12PM -0400, Alexandre Quessy wrote: Hello everyone 2010/8/17 Alexandre Quessy : 2010/8/15 Alexandre Quessy : 2010/8/15 Jonas Smedegaard : 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 Mon, Aug 30, 2010 at 10:26:12PM -0400, Alexandre Quessy wrote: Hello everyone 2010/8/17 Alexandre Quessy : 2010/8/15 Alexandre Quessy : 2010/8/15 Jonas Smedegaard : 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
Hello everyone 2010/8/17 Alexandre Quessy : > 2010/8/15 Alexandre Quessy : >> 2010/8/15 Jonas Smedegaard : >>> 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 : > 2010/8/15 Jonas Smedegaard : >> 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
Hello Jonas, I see you have done more work on these packages. Nice. 2010/8/15 Jonas Smedegaard : > 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 Fri, Aug 06, 2010 at 09:59:27AM -0400, Alexandre Quessy wrote: Hello again, 2010/7/31 Alexandre Quessy : 2010/7/26 Jonas Smedegaard : 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 again, 2010/7/31 Alexandre Quessy : > 2010/7/26 Jonas Smedegaard : >> Ok. > > So? Are we close to the upload time? It seems to me we have solved the > most important issues with this packaging. The version packaged is now > the latest of the 0.6 stable branch. This software will be a useful > contribution to Debian, I believe. Any ETA on this? :) (sorry to keep pinging you) I think this package is a good candidate to be part of squeeze, the next release of Debian. Best, -- Alexandre Quessy http://alexandre.quessy.net/ ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
Hello! 2010/7/26 Jonas Smedegaard : > > 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. 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
On Sun, Jul 25, 2010 at 09:06:34PM -0400, Alexandre Quessy wrote: 2010/7/22 Jonas Smedegaard : 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 : > 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
On Thu, Jul 22, 2010 at 02:28:11PM -0400, Alexandre Quessy wrote: 2010/7/20 Jonas Smedegaard : On Tue, Jul 20, 2010 at 12:16:38PM -0400, Alexandre Quessy wrote: On 10-07-20 12:07 PM, Alexandre Quessy wrote: 2) Replace the shebang by the proper Python version We still need to set up the /usr/bin/python2.6 thing. That's still to do. I think it's to be done in the Debian packaging. (the upstream authors can really well apply some patches later on) Ok. Also, I have problems with installing the Python modules in the right package. (the scenic and midistream binary packages are the ones that contain Python modules. Namely the scenic and midistream modules) Do you mean "we" as upstream or hack it in packaging? I meant "we" as the Debian packagers. I think the Python work is OK upstream. Now, we just need to package it for Debian. There are two Python modules and some Python executables. I wanted to create two packages for this: scenic and midistream. Upstream, it's all packaged using the autotools. Ok. I am having another look at it now... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
Hello Jonas and all, 2010/7/20 Jonas Smedegaard : > 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
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 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
-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 CfOvznxMrZf
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 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
Hi Alexandre (and others), On Sun, Jun 20, 2010 at 11:51:10AM -0400, Alexandre Quessy wrote: On 10-06-11 07:11 PM, Jonas Smedegaard wrote: Hmmm. I see now that your Makefile.in for the python code uses $(libdir) and not $(pythondir). This causes the code to not use standard Python paths, so that a) it is not possible to support multiple concurrent Python versions, and b) you need to explicitly tell pysupport where the custom files are stored so that it can properly ensure Python Policy is followed. Right now the files are simply installed - not handled properly :-( This has been fixed upstream in the release 0.6.2! I imported the new tarball in the repository, and it seems to compile OK. What I didn't get yet, is how to install the Python module for each binary package. The "scenic" Python module should be shipped with the "scenic" Debian package; the "rtpmidi" Python module with the "midistream" .deb. I played with the debian/rules a bit and read more about dh_pysupport. I am still not sure of how I should do this. Any suggestion? From a quick glance it seems that your latest attempts are wrong. I had a go at compiling now (my earlier laptop disk space problems have been solved now!) but unfortunately didn't make it far enough to look at this issue. I improved build-dependencies on Boost libs. This shouldn't affect the buildability. Python scripts are invoked directly, causing default Python to always be used, ignoring autotools $(PYTHON) variable. This is only an issue on systems that wants to build for a non-default Python version (i.e. not currently a problem with Debian). I believe the best fix is to use the autotools-provided $(PYTHON) (and the related python prefix variable - I forgot its variable name) to compose the hashbang from a .in file of the scripts, instead of the current "/usr/bin/env python" construct. Python scripts rely on local modules that are a) not declared and b) not yet built. I fixed a) with a patch, but b) still fails. I believe the help2man rules need to depend on module building, and the patch then changed to use build dir instead of source dir (which is wrong to use in any case). Another issue is weak cleanup. During build, directories and files are created, which are not cleaned up in the clean target. I have worked around this in the packaging by forcefully removing the build directory, so not urgent to fix, just would improve elegancy of upstream build routines :-) Another more annoying issue is that upstream autotools do not use AM_MAINTAINER_MODE, causing normal builds to regenerate autotools if "too old" which might happen accidentally, especially when using a VCS as we do. The fix upstream is simple: Add AM_MAINTAINER_MODE to configure.am and all should be fine. Until then we need to do a clumsy workaround of preserving upstream autotools and restoring in our clean rule. Sorry for my silence - I have been busy with Real Life. I am really excited about this package, as it seems to provide quite cool functionality that I am really looking forward to play with :-) Hope this helps, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
-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
Hello Jonas, On 10-06-11 07:11 PM, Jonas Smedegaard wrote: > > 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. > So, I think we will not make for The Ubuntu freeze on June 24th. :( That's too bad. I wish I had enough knowledge and experience and packaging to solve this right away. The upstream team would have liked to make it for the next Ubuntu Maverick, so that we could ask it to be bacported to Lucid. (the current Long-Term-Support Ubuntu distro) Anyways, as I said before, it is likely that I will package more software containing both Python and C++ code, so it is an important exercise, I guess. If anyone has suggestions on readings or trials I can make, don't hesitate to tell me. Later, Alexandre ___ 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
[commenting on other parts - missed in my first reply] On Sat, Jun 12, 2010 at 10:04:22AM -0400, Alexandre Quessy wrote: 2010/6/11 Jonas Smedegaard : 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. Hmm, ok. Another time I recommend that if something goes wrong while importing upstream source then roll back - i.e. do something like the following: gil log # verify if indeed the latest commit should be killed git reset --hard HEAD^ git checkout upstream gil log # verify if indeed the latest commit should be killed git reset --hard HEAD^ git checkout pristine-tar gil log # verify if indeed the latest commit should be killed git reset --hard HEAD^ git checkout master It is too late now that you've pushed your changes. As I wrote in my earlier response, I recommend to do a git-import-orig again with same original tarball, on top of this half-baked import. That shouldn't cause any harm, just create a bit of add-on commit noise and hopefully generate proper release tag. Oh, and I suggest you have a look at including the CDBS snippet upstream-tarball.mk, add hints about upstream tarball location and naming to debian/control and try do a get-orig-source. If interested in that (personally I find it one of the coolest snippets - but obviously I am biased), then now - before importing again - is an excellent time to do it ;-) Are you sure you did not rename a bzip2 tarball or something? The upstream tarball is a .tar.gz, not a bz2. Ok. That was not the cause then. I see there are two tarballs in the pristine-tar branch. I guess I should remove the old one? No! Let tarball chunks slowly pile up in pristine-tar - that is by design, and we save no space by cleaning up. 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. My guess is that indeed it stopped with warnings. But after having completed parts of the import. Here's my understanding of what happens during a git-import-orig: 1. import tarball contents to upstream branch 2. generate and commit binary diff to pristine-tar branch 3. tag upstream branch 4. sync upstream and master branches Step 3 above probably failed for you, since you used signed tagging but had not yet educated your git environment about your name and email. Oh - if you are new to git, then here's a cool little gem: git config --global color.ui auto 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 Sat, Jun 12, 2010 at 10:04:22AM -0400, Alexandre Quessy wrote: Hello Jonas! 2010/6/11 Jonas Smedegaard : 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 Jonas! 2010/6/11 Jonas Smedegaard : > > 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. 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
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 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
Hello ! > > I should import a new original tarball within a few hours. The 0.6.1 > upstream release is out. > It's online! I hope everything is OK. -- 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! >> >> 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 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 : 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! 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 : > > 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 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 Jonas and everyone!
I greatly appreciate your help, by the way. :)
2010/6/8 Jonas Smedegaard :
>
> 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
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 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 : 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 : > 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Jonas and the list! On 10-06-05 03:51 AM, Jonas Smedegaard wrote: > Lower that package relation to suggests, and document the benefit of > installing that suggestion (without explaining the reason it is only > suggested, that is development-grade info IMO) in both long description > (i.e. in debian/control) and in a debian/README.Debian file (which CDBS > then automagically includes in the binary packages). > Done. > And try post to bug#544347 again - cc'ing menucci who seem to have > somewhat taken over maintainership and perhaps haven't noticed that old > bug. > Done. >> Maybe it would be nice to also create the scenic-doc package, to >> separate the doc from the Python code. (though both are architecture: >> all) > > Certainly - if there is documentation of a reasonable amount then it > should be in a separate binary package. > Done. :) > >> For now, the docbook documentation (viewable with yelp) are in an >> unusual location. (/usr/share/scenic/docbook) It should probably go to >> /usr/share/gnome/help/scenic/C/scenic.xml like all gnome docs. Our >> docbook doc is made of several XML files and images, though, and we >> have two manuals... > > I am not very familiar with yelp, but seems to me that if the project is > not otherwise tied specifically to Gnome and if yelp supports reading > from non-gnome directories, then you shouldn't jump through hoops to > install the documentation Gnome-style, but instead jump through hoops to > get yelp to recognize it. More importantly you should register with > doc-base (which might be all that is needed for yelp integration too?). > Each .doc-base file must be for the doc of only one binary package, but there are two manuals in Scenic! (not that I agree with that...) Meanwhile, my current .doc-base file is installed properly, but it is not shown by dhelp. > Well, my excuses currently is a) I have too little time (developing and > setting up sms service in the field for an experimental theater group), > and b) I cannot do clean-room package compilations due to a major part > of my laptop being readonly (heating problem caused a power outage > during a partition resize - all data seems fine but I cannot know for > sure, and every time I try fsck'ing that heating problem strikes again). > > In other words: my trouble is unrelated to the code quality :-) > Don't worry. Me and the Scenic team has tested it a lot since the last few months, and on Debian unstable as well. There is no Trojan horse in the app! - only an easter egg. I wish you to overcome these technical problems quickly. Here is a list of the current lintian warnings for the four packages: - -- scenic-doc aa...@plouf:~/src/debian/build-area$ lintian -Iv --pedantic scenic-doc_0.5.11-1_i386.deb N: Setting up lab in /tmp/k1R8QxDI2F ... N: Processing 1 packages... N: N: Processing binary package scenic-doc (version 0.5.11-1) ... P: scenic-doc: no-upstream-changelog N: Removing /tmp/k1R8QxDI2F ... - --- scenic aa...@plouf:~/src/debian/build-area$ lintian -Iv --pedantic scenic_0.5.11-1_all.deb N: Setting up lab in /tmp/EfBpUFMNoH ... N: Processing 1 packages... N: N: Processing binary package scenic (version 0.5.11-1) ... P: scenic: no-upstream-changelog I: scenic: hyphen-used-as-minus-sign usr/share/man/man1/scenic.1.gz:52 I: scenic: unused-override scenic source: hyphen-used-as-minus-sign N: Removing /tmp/EfBpUFMNoH ... - midistream aa...@plouf:~/src/debian/build-area$ lintian -Iv --pedantic midistream_0.5.11-1_all.deb N: Setting up lab in /tmp/DSFZ66tQGW ... N: Processing 1 packages... N: N: Processing binary package midistream (version 0.5.11-1) ... P: midistream: no-upstream-changelog I: midistream: hyphen-used-as-minus-sign usr/share/man/man1/midistream.1.gz:70 I: midistream: hyphen-used-as-minus-sign usr/share/man/man1/midistream.1.gz:76 I: midistream: hyphen-used-as-minus-sign usr/share/man/man1/midistream.1.gz:81 I: midistream: unused-override midistream source: hyphen-used-as-minus-sign N: Removing /tmp/DSFZ66tQGW ... >>> sugar-0.88 >>> >>> That one also demonstrates quite well IMO how a large amount of >>> package dependencies are easier to track indirectly declared in >>> debian/rules, as they they can be grouped and comments added as needed. >>> >> >> This is very interesting and am I looking forward to learn more about >> this. I will make some tests soon. > > I am happy to hear that you are interested in those features. They are > some of my newest additions to CDBS :-) > Should I get into that for the first package of Scenic? How new is it? I am looking forward to use these advanced goodies, but I am still a beginner at packaging... :) Best regards, Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgA
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 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
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 : > 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 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 :-) - 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 12:55:32AM -0400, Alexandre Quessy wrote: 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. Lower that package relation to suggests, and document the benefit of installing that suggestion (without explaining the reason it is only suggested, that is development-grade info IMO) in both long description (i.e. in debian/control) and in a debian/README.Debian file (which CDBS then automagically includes in the binary packages). And try post to bug#544347 again - cc'ing menucci who seem to have somewhat taken over maintainership and perhaps haven't noticed that old bug. A valuable place for extracting such info is this: http://packages.qa.debian.org/p/pygame.html 2010/6/4 Jonas Smedegaard : Maybe it would be nice to also create the scenic-doc package, to separate the doc from the Python code. (though both are architecture: all) Certainly - if there is documentation of a reasonable amount then it should be in a separate binary package. For now, the docbook documentation (viewable with yelp) are in an unusual location. (/usr/share/scenic/docbook) It should probably go to /usr/share/gnome/help/scenic/C/scenic.xml like all gnome docs. Our docbook doc is made of several XML files and images, though, and we have two manuals... I am not very familiar with yelp, but seems to me that if the project is not otherwise tied specifically to Gnome and if yelp supports reading from non-gnome directories, then you shouldn't jump through hoops to install the documentation Gnome-style, but instead jump through hoops to get yelp to recognize it. More importantly you should register with doc-base (which might be all that is needed for yelp integration too?). 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 GUI should work right away. For the command-line lovers, the "advanced" tutorials in the "User manual" under the "Help" menu are a good intro to the "milhouse" command-line tool. Well, my excuses currently is a) I have too little time (developing and setting up sms service in the field for an experimental theater group), and b) I cannot do clean-room package compilations due to a major part of my laptop being readonly (heating problem caused a power outage during a partition resize - all data seems fine but I cannot know for sure, and every time I try fsck'ing that heating problem strikes again). In other words: my trouble is unrelated to the code quality :-) 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. This is very interesting and am I looking forward to learn more about this. I will make some tests soon. I am happy to hear that you are interested in those features. They
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
Hello again! Just a quick update: I have create the 3 .install and .manpages files. I think it doesn't make sense to separate the libraries from at least the milhouse command-line tool, since they are used by it or with it only. I am still thinking about splitting the doc from the scenic package or not. I have filled an ITP bug for python-portmidi. Later, Alex 2010/6/5 Alexandre Quessy : > Hello! > > 2010/6/5 Alexandre Quessy : >> 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 : >>> 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 : > > 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/PackagesC
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
Hello! 2010/6/5 Alexandre Quessy : > 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 : >> 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 : 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 midi
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
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 : > 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 : >>> >>> 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) 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 GUI should work right away. For the command-line lover
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 : 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 Jonas, So I have set up a Debian sid box. That will help. :) 2010/6/4 Jonas Smedegaard : > On Thu, Jun 03, 2010 at 11:59:18AM -0400, Alexandre Quessy wrote: > >> Done. I will have to add your license to the copyright of some of the >> Debian packaging. > > What I do is maintain packaging licensing in debian/rules. And I (ideally, > when not too lazy) do not add licensing info of others but instead request > them to add it themselves. ;-) > 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 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
On Thu, Jun 03, 2010 at 12:13:11PM -0400, Alexandre Quessy wrote: 2010/6/3 Jonas Smedegaard : Some additional packaging comments: The project includes python code. We must then follow to Debian Python Policy! Since the Python code apparently is all handled with GNU autotools I recommend to include python-autotools.mk (instead of autotools.mk), add the needed hints to debian/control, and create debian/control.in to help track CDBS-related build-dependencies. 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
Hello! By the way, I will setup a Debian sid box tomorrow... If that can reassure you guys on my sincerity. :) I used to use mainly Debian for at least a year, but got lazy since Ubuntu is so easy - but there's a tradeoff to it. Anyways, back to work! a 2010/6/3 Felipe Sateler : > On Thu, Jun 3, 2010 at 11:59, Alexandre Quessy 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 > -- 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 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 again. :) 2010/6/3 Jonas Smedegaard : > Some additional packaging comments: > > The project includes python code. We must then follow to Debian Python > Policy! > > Since the Python code apparently is all handled with GNU autotools I > recommend to include python-autotools.mk (instead of autotools.mk), add the > needed hints to debian/control, and create debian/control.in to help track > CDBS-related build-dependencies. > 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
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 : > On Wed, Jun 02, 2010 at 10:52:23PM -0400, Alexandre Quessy wrote: >> >> 2010/6/2 Jonas Smedegaard : >>> >>> After a nice meal I now have some comments on your packaging: >>> >>> First of all: Please package using git-buildpackage and upload to the >>> pkg-multimedia repository - more info here: >>> http://wiki.debian.org/DebianMultimedia/DevelopPackaging >>> >> >> 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 usef
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
On Thu, Jun 3, 2010 at 06:23, Jonas Smedegaard wrote: > As a related not, there are several ways to keep track of packaging changes, > common ones being dch+dcommit and git+git-dch. > > Probably the most common one generally in Debian is to make your packaging > change, add a changelog entry using dch, and commit both the actual change > and the changelog update using dcommit. > > I prefer the alternative of making packaging changes, commit the actual > change, and only occationally (and at minimum right before a packaging > release) do a git-dch, maybe adjust the changelog file by hand (e.g. I > prefer to add a newline before bug-closures for improved readability), and > then commit the changelog update separately from the actual code changes. > > One thing I like about that git+git-dch approach is the code changes being > separate, which eases potential later reverts or cherry-picking across > branches. Note that the team policy is to generate the changelog with git-dch at release time, precisely due to cherry-pick and revert ease. This is documented in the wiki page. -- 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
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
On Wed, Jun 02, 2010 at 10:52:23PM -0400, Alexandre Quessy wrote: 2010/6/2 Jonas Smedegaard : After a nice meal I now have some comments on your packaging: First of all: Please package using git-buildpackage and upload to the pkg-multimedia repository - more info here: http://wiki.debian.org/DebianMultimedia/DevelopPackaging 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. (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!). I pushed my changes again to alioth. Should I update the vesion number to 0.5.11-2 now? I know that when it's ready to upload we should keep only the last entry - with the "Initial packaging" message - closing the ITP bug. Generally for all Debian packaging we should bump the release number only when actually releasing as packaging in Debian. So the answer is "No!". As a related not, there are several ways to keep track of packaging changes, common ones being dch+dcommit and git+git-dch. Probably the most common one generally in Debian is to make your packaging change, add a changelog entry using dch, and commit both the actual change and the changelog update using dcommit. I prefer the alternative of making packaging changes, commit the actual change, and only occationally (and at minimum right before a packaging release) do a git-dch, maybe adjust the changelog file by hand (e.g. I prefer to add a newline before bug-closures for improved readability), and then commit the changelog update separately from the actual code changes. One thing I like about that git+git-dch approach is the code changes being separate, which eases potential later reverts or cherry-picking across branches. Another related note is how to handle Debian-based non-Debian packaging releases. I prefer to treat Debian as the master, do variations off of that, and not include "noise" from derived packaging in the main Debian branch. If I borrow from e.g. an Ubuntu packaging not done by myself, then I cherry-pick the actual packaging code changes but do not preserve the derived changelog entries: Debian IMO have no use of documenting version numbers not ever being released in a Debian context! Long descriptions should be line-wrapped at 72 chars. Done. (I thought it was 80) The classic terminal width is 80 chars. A common line-wrapping length is 72 chars to leave some chars for e.g. quoting in MUAs. So yes, I wouldnt be surprised if the Debian Policy limit is 80 chars, but I will nevertheless still recommend to use 72 chars in reality :-) 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. I am not sure where you found this. Was it in scenic 0.5.10-2? I am now editing starting from 0.5.11-1, in which I can't find any dh_install. Yes, I looked at the packaging that you originally provided a URL for, which indeed was 0.5.10-2. Now we are both tracking same Git and you are right, it is gone :-) Are you sure you need to build-depend on bash-completion? No. :) Removed it. I assume the /etc/bash_completion.d/ directory will be created? If not, I should create it? Yes, in my experience underlying directories are automagically created when installing files through debhelper. Not sure what version of debhelper started doing so, but I am pretty confident that at least version 5 is safe. 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. 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-*. 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 o
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
Hello Jonas and the team! 2010/6/2 Jonas Smedegaard : > After a nice meal I now have some comments on your packaging: > > First of all: Please package using git-buildpackage and upload to the > pkg-multimedia repository - more info here: > http://wiki.debian.org/DebianMultimedia/DevelopPackaging > Done. Everything seems to be OK, as far as I know. I push the 0.5.11-1 I had made, and then committed some changes according to your advices. I pushed my changes again to alioth. Should I update the vesion number to 0.5.11-2 now? I know that when it's ready to upload we should keep only the last entry - with the "Initial packaging" message - closing the ITP bug. > When you have switched to Git, then add Vcs-Git and Vcs-Browser stanzas to > the control file. OK. Done. > > 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). Was already done. :) > > Long descriptions should be line-wrapped at 72 chars. > Done. (I thought it was 80) > Avoid stray spaces at end of lines (noticed in long description, but should > be avoided everywhere). Done. > > 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. I removed them. > > 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. > Ok. Done. > 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. > I removed them. They were non-free packages. I think they are on Ubuntu, but not on Debian. They are not needed for a successful build, so I removed them. I might add some suggests in a future version of this package. > 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. I assume this in the rules file. I changed it according to your advice: DEB_CONFIGURE_EXTRA_FLAGS = --enable-mt > > 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. > I am not sure where you found this. Was it in scenic 0.5.10-2? I am now editing starting from 0.5.11-1, in which I can't find any dh_install. > Are you sure you need to build-depend on bash-completion? > No. :) Removed it. I assume the /etc/bash_completion.d/ directory will be created? If not, I should create it? > 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-*? > 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. > 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 . > Done. They're all passed here. :) > H
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
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 : > 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 : > 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
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 : I use cdbs, but I am ready to switch to debhelper 7 if we fix some issues I had with it. (we need to build it with --enable-mt) What is your own preference here? Do you want to continue using CDBS if that is acceptable, or do you not like CDBS and prefer yourself to get rid of it? Well, I would rather stick with CDBS for now, since it works for this package. I tried to switch to debhelper 7, but it didn't work at the first try. Great! I am dead hungry (and in Italy this week, so looking forward to the food quality here in Torino!), but will try have a look at your packaging later tonight, and get back yo you. If the first, then I will be happy to work with you - I only use CDBS and is quite happy with it. If the latter then I will rather not spend time on this, but leave it to others in this team to work with you :-) Wow! I am very impressed by the list of packages you are working on. I would be very happy to work with you for this package! My long-time will is to become a DD, mostly for multimedia. He he - year, the list grows... :-) I am very happy to hear that you are aiming long-term for becoming a developer. I will do my best to help you with that! For this scenic package, I will release the 0.5.11 tag in a few hours today. (I'm in Montreal, so my time zone is -0400) My packaging is pretty much ready and our big app is very stable right now. I think there is not much work left to do. You don't know me - I am pretty sure I will find some nitpicking to do :-P You can find me on the #debian-multimedia IRC channel, if you want. I try to avoid realtime chat, as it is so very fun and thus steal too much of my time :-/ - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
Hello Jonas, 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. 2010/6/2 Jonas Smedegaard : > Hi Alexandre, > > On Wed, Jun 02, 2010 at 10:42:27AM -0400, Alexandre Quessy wrote: > >> As a new member of this team, I would like to find a sponsor for the >> scenic package. > > There is sponsoring, and there is team maintainance. They are two different > styles of working together. > > With sponsoring you maintain your package alone, and then hand it over to > someone with upload rights who "sign" your package (after inspecting its > sanity and perhaps requesting you to improve some things or doing some > improvements themselves). > > With team maintainance you work on a package - maybe alone, maybe with > others in the team, and when you/they feel the package is ready for release > you shout here at the list for someone with upload rights to finalize and > upload. > > > The difference is not only in concrete working style, but also in who takes > responsibility towards the users in the wuality assurance of the package: A > team or a single developer. > > > Since you mention that you are part of our team (sorry - I did not know, I > am lousy at keeping track of such things), I guess what you really want is > not "sponsoring" at all, but just some fellow team member to help finalize > and upload :-) > Yes, I am member of team since of few days only. I've been a free software developers for years, and a big fan of Debian and Ubuntu, though. So yes, I want to work with the Debian Multimedia team. > >> 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. > > 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. 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 can find me on the #debian-multimedia IRC channel, if you want. Best, Alex > > 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 > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIcBAEBCgAGBQJMBn/CAAoJECx8MUbBoAEh5IEP+gJFmVQu/FRWNz9n5qs8fmM1 > LQXYBJGu/dRknOyEfxAzW126K8cz82ryVxzBI5NPGF8OEV+HRlp5RtsRAfJf+ebS > 4dIhxXQz4KLYwQe0FySm8rTeaxwNwQes2ooR2KddyC8aFf9Wvk8csT7ZBuq0B0Q2 > BHDHHUGvkcMPNJwX8Dvhs/JkTz0gGcVvIMOHHX/xLkgyBaPMzzmqptH1TPJtnsNI > LAsnzOPjpyypI8eLvJCCpjLkOT5pYtWQKbu/+d80zgd0irIvjS5GJ0uagtmCS1o3 > 6nCzVHae94aSC88cNZmz5Ke+Dg4WSkzx/GOMUrNOylAnkiNaRrLU2oQv1La/AdWc > 1icVEWzVAet1RLNUxxqaGiaXADrPjIbY2C8Y/MlJ625B8XfbA91l5DXDg5CAQ/7w > l3/dRq3XGXFdWWarohsxaSHFAWxXis1eMHaDY2y343OqtbTcp7dLH7ZQO/A7vS+U > UTxwj8kJERv1JXkPI4znE/sVTDHUGbGAc3iWUDHe7GkAsaq5m/fENviSuPI2/d5t > 5zk1tHOgH2kiE5FYqLWzQVARJomGbwwvXjKE4pCWdpX7iJStnef1AkZKz3yCtb0E > UuowTOU9KD0t3JZaIb8PkWmzCFVfWdHdoMb8IDeFeq5vxWZN4plUlIFk3P7oOJMW > 4+vhlcfLCMC3xdu8F79X > =2RxN > -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
Hi Alexandre, On Wed, Jun 02, 2010 at 10:42:27AM -0400, Alexandre Quessy wrote: As a new member of this team, I would like to find a sponsor for the scenic package. There is sponsoring, and there is team maintainance. They are two different styles of working together. With sponsoring you maintain your package alone, and then hand it over to someone with upload rights who "sign" your package (after inspecting its sanity and perhaps requesting you to improve some things or doing some improvements themselves). With team maintainance you work on a package - maybe alone, maybe with others in the team, and when you/they feel the package is ready for release you shout here at the list for someone with upload rights to finalize and upload. The difference is not only in concrete working style, but also in who takes responsibility towards the users in the wuality assurance of the package: A team or a single developer. Since you mention that you are part of our team (sorry - I did not know, I am lousy at keeping track of such things), I guess what you really want is not "sponsoring" at all, but just some fellow team member to help finalize and upload :-) I use cdbs, but I am ready to switch to debhelper 7 if we fix some issues I had with it. (we need to build it with --enable-mt) What is your own preference here? Do you want to continue using CDBS if that is acceptable, or do you not like CDBS and prefer yourself to get rid of it? If the first, then I will be happy to work with you - I only use CDBS and is quite happy with it. If the latter then I will rather not spend time on this, but leave it to others in this team to work with you :-) Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
Hello dear members of the pkg-multimedia team, As a new member of this team, I would like to find a sponsor for the scenic package. 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) I'm much active on the IRC. a -- Forwarded message -- From: Alexandre Quessy Date: 2010/6/2 Subject: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations To: debian-ment...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "scenic". I would like this package to be maintained by the pkg-multimedia team. * Package name : scenic Version : 0.6.0-1 Upstream Authors: Tristan Matthews Alexandre Quessy Simon Piette Philippe Chevry Koya Charles Antoine Collet Sylvain Cormier Etienne Desautels Hugo Boyer * URL : http://svn.sat.qc.ca/trac/scenic * License : GPL v2 or later Copyright holder: Society for Arts and Technology Section : net It builds these binary packages: scenic - Telepresence software for live performances and installations Scenic is a free software suite for streaming audio, video and MIDI between live events. It was created at the Society for Arts and Technology (SAT) to give artists a powerful tool for telepresence in live arts contexts and new media installations. The streaming is done over RTP with the GStreamer multimedia framework. Users can also choose low-bandwidth or high-quality codecs, depending on what is available on their system. It offers up to as many audio channels as your audio device supports. Scenic consists in a desktop application and several command-line utilities: * scenic: Desktop application to stream audio, video and MIDI over RTP * milhouse: Streams audio and video over RTP * midistream: Streams MIDI notes and controls over RTP * dc-ctl: Controls connected DC IEEE 1394 cameras * firereset: Resets a IEEE 1394 bus to help in case of problems * jack-info: Prints informations about running JACK servers The package appears to be lintian clean. My motivation for maintaining this package is: I am one of the upstream authors. I have other related packages that will be ready to upload soon. Debian and Ubuntu are my favourite operating system. I want to become a package maintainer and some day a Debian developer. I am a free software enthusiast. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/scenic - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/scenic/scenic_0.5.10-2.dsc - Page on mentors: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=scenic NOTE: The current version on mentors is 0.5.10-2, but I should release a 0.5.11-1 soon. (see on mentors.debian.net) I want to fix issues that the mentor might point and release the 0.6.0-1 version for uploading it to Debian. Kind regards Alexandre Quessy http://alexandre.quessy.net -- 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
