Hello again! I just thought about an issue that makes my package 33% unusable. :) The MIDI streaming feature (which would be provided by the new midistream package) relies on either python-portmidi or python-pygame >= 1.9.1. Those two packages are not in Debian yet!
Actually, python-pygame 1.9.1 is in Ubuntu Lucid, but not in Debian Sid. I have been trying to contact the maintainer, and later answered to a bug about this. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544347 ... Maybe it is too late before the the release of Squeeze? There might be quite a few packages that depend on python-pygame. I also have an other package - toonloop 1.2.8 - that needs python-pygame, for its V4L2 video input feature and the MIDI feature. For the MIDI feature, which is our main interest for scenic, an other package could provide it. It's python-portmidi. I packaged it, but did not contribute it yet, since the original author thought it would be nice to send it upstream, but it's taking time. It's not there yet: http://sourceforge.net/apps/trac/portmedia/browser/portmidi/trunk (4 months with no activity) My changes to the upstream along with my packaging files are at http://bitbucket.org/aalex/pyportmidi/wiki/Home So, either we ask the maintainers of the pygame package to update it, or we package python-portmidi. I think that merging the pyportmidi code with portmidi0 would take too much time and effort for now. (before Squeeze) Anyways, the python-portmidi should be a separate package from portmidi0, so ... should fill a ITP and package it now? :) Note that the scenic application can still run, it's only that the MIDI features will be disabled. (more text below...) 2010/6/4 Jonas Smedegaard <d...@jones.dk>: > On Fri, Jun 04, 2010 at 04:57:40PM -0400, Alexandre Quessy wrote: >> >> Hello Jonas, >> >> So I have set up a Debian sid box. That will help. :) > > Good! > > >> 2010/6/4 Jonas Smedegaard <d...@jones.dk>: >>> >>> On Thu, Jun 03, 2010 at 11:59:18AM -0400, Alexandre Quessy wrote: >>> >>>> Done. I will have to add your license to the copyright of some of the >>>> Debian packaging. >>> >>> What I do is maintain packaging licensing in debian/rules. And I >>> (ideally, when not too lazy) do not add licensing info of others but instead >>> request them to add it themselves. ;-) >>> >> >> Oops! I added your name to debian/copyright. Please edit it or remove it >> if it's not the way you like. > > No problem. I only tried to aim at a best practice. :-) > > >>>>> It does seem, however, from a quick glance, that some parts of the >>>>> project is not arch-limited. It might be a good idea to split packaging >>>>> to >>>>> provide most possible to all archs. >>>>> >>>> >>>> That would be nice, but it's probably going to be difficult. The >>>> jack-info, dc-ctl and midistream utilities could be packages separately, >>>> and >>>> should be useful for the multimedia-loving masses. Since scenic relies on >>>> milhouse, they could be packaged together. Again, I am a close-to-beginner >>>> in packaging, so I am not sure where to start, especially that the current >>>> build process is unified and using a single autotools configure.ac script. >>>> It would imply splitting it upstream, no? >>> >>> Packaging typically goes like this: >>> >>> 1. Prepare >>> 2. configure >>> 3. build >>> 4. install >>> 5. reinstall into package area >>> 6. tune packaging >>> >>> Here, steps 2-4 is done by autotools, and 5-6 is done by debhelper. >>> >>> So splitting into multiple packages is (more or less) a simple matter of >>> adding more binary packages in debian/control and hinting in >>> debian/*.install which autotools-installed parts each of them should >>> contain. >>> >> >> Ok, so in this case, let's say we brake it into 3 packages: >> >> * scenic (contains the Python app, the documentation, the glade data, >> and the icon, etc.) >> * scenic-utils (dc-ctl, firereset, jack-info and milhouse >> executables. Man pages and some shared libraries) >> * midistream (python app and man page) >> Maybe it would be nice to also create the scenic-doc package, to separate the doc from the Python code. (though both are architecture: all) 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 lovers, the "advanced" tutorials in the "User manual" under the "Help" menu are a good intro to the "milhouse" command-line tool. > >> 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. Later, Alex > > - 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) > > iQIcBAEBCgAGBQJMCYEZAAoJECx8MUbBoAEhKXAP/2q8119/HgJP2BD856hY+P2l > wQWaq+sQrG5E7jZX+n9TWu/uB/p8dYdp3LZ57a6LDD7r/ogjEi69tcXV6hpanyYr > 4+zE+DGPp1dj+wgOPmJWOUrhqR/Qcvm/MDiRBHUt2M/XX5iPkDR1NIpSjgoZJEAP > WqOam84408ni0gKTKH5SDvHJqU9P5cuT5zMKi5Au8oKE+wcnW/2UXmKwFiNvLITQ > SfTZ/0ECF2JozdF9j+mp+Q78QnU/zyTkj2keElN980lubp++WmFeBg52Xfn0P7Lf > SeBbddZ24hYKA8duJb1cuKrmswmsIkglYNlguep+8JYi41NZ2eZRCI2lmylJZ9Pd > YwLgVXnRUwvMgIorRIfiSFnfEhU3PTjMyGPSa88VfmDxJWTIH14MeV6oqhSlmU5t > 6gO3oP9jX2P85TeKNXvg3xqL6yPf+hner+UGuFh0idKvjRpmq1H7FCnbJ60lb/y+ > ugyC0fRwVG4E3y6OhQ70GTQvVmQLgZMxB8RV3vM+IlNgZxEP4u+VLxcil8Ks2ERh > zni8ApChFsL17buk6anBPUwSzF1s6UJiT/TQ0lfcgd8hS9BiteKpVPkd6lwqL8aB > dgSB8pyYn6tUoFgNNWldwvtAXatnTxUioJJzTGlbcj/D/6qDNO+wJsKDvDG4mUDo > WjN/P76euTwVEy16XxVR > =dUhs > -----END PGP SIGNATURE----- > > _______________________________________________ > pkg-multimedia-maintainers mailing list > email@example.com > http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers > > -- Alexandre Quessy http://alexandre.quessy.net/ _______________________________________________ pkg-multimedia-maintainers mailing list firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers