Hello! 2010/6/5 Alexandre Quessy <alexan...@quessy.net>: > Hello again! > > I just thought about an issue that makes my package 33% unusable. :) > The MIDI streaming feature (which would be provided by the new > midistream package) relies on either python-portmidi or python-pygame >>= 1.9.1. Those two packages are not in Debian yet! > > Actually, python-pygame 1.9.1 is in Ubuntu Lucid, but not in Debian > Sid. I have been trying to contact the maintainer, and later answered > to a bug about this. See > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544347 ... Maybe it > is too late before the the release of Squeeze? There might be quite a > few packages that depend on python-pygame. I also have an other > package - toonloop 1.2.8 - that needs python-pygame, for its V4L2 > video input feature and the MIDI feature. > > For the MIDI feature, which is our main interest for scenic, an other > package could provide it. It's python-portmidi. I packaged it, but did > not contribute it yet, since the original author thought it would be > nice to send it upstream, but it's taking time. It's not there yet: > http://sourceforge.net/apps/trac/portmedia/browser/portmidi/trunk (4 > months with no activity) My changes to the upstream along with my > packaging files are at http://bitbucket.org/aalex/pyportmidi/wiki/Home > > So, either we ask the maintainers of the pygame package to update it, > or we package python-portmidi. I think that merging the pyportmidi > code with portmidi0 would take too much time and effort for now. > (before Squeeze) Anyways, the python-portmidi should be a separate > package from portmidi0, so ... should fill a ITP and package it now? > :) > > Note that the scenic application can still run, it's only that the > MIDI features will be disabled. > > (more text below...) > > 2010/6/4 Jonas Smedegaard <d...@jones.dk>: >> On Fri, Jun 04, 2010 at 04:57:40PM -0400, Alexandre Quessy wrote: >>> >>> Hello Jonas, >>> >>> So I have set up a Debian sid box. That will help. :) >> >> Good! >> >> >>> 2010/6/4 Jonas Smedegaard <d...@jones.dk>: >>>> >>>> On Thu, Jun 03, 2010 at 11:59:18AM -0400, Alexandre Quessy wrote: >>>> >>>>> Done. I will have to add your license to the copyright of some of the >>>>> Debian packaging. >>>> >>>> What I do is maintain packaging licensing in debian/rules. And I >>>> (ideally, when not too lazy) do not add licensing info of others but >>>> instead >>>> request them to add it themselves. ;-) >>>> >>> >>> Oops! I added your name to debian/copyright. Please edit it or remove it >>> if it's not the way you like. >> >> No problem. I only tried to aim at a best practice. :-) >> >> >>>>>> It does seem, however, from a quick glance, that some parts of the >>>>>> project is not arch-limited. It might be a good idea to split packaging >>>>>> to >>>>>> provide most possible to all archs. >>>>>> >>>>> >>>>> That would be nice, but it's probably going to be difficult. The >>>>> jack-info, dc-ctl and midistream utilities could be packages separately, >>>>> and >>>>> should be useful for the multimedia-loving masses. Since scenic relies on >>>>> milhouse, they could be packaged together. Again, I am a close-to-beginner >>>>> in packaging, so I am not sure where to start, especially that the current >>>>> build process is unified and using a single autotools configure.ac script. >>>>> It would imply splitting it upstream, no? >>>> >>>> Packaging typically goes like this: >>>> >>>> 1. Prepare >>>> 2. configure >>>> 3. build >>>> 4. install >>>> 5. reinstall into package area >>>> 6. tune packaging >>>> >>>> Here, steps 2-4 is done by autotools, and 5-6 is done by debhelper. >>>> >>>> So splitting into multiple packages is (more or less) a simple matter of >>>> adding more binary packages in debian/control and hinting in >>>> debian/*.install which autotools-installed parts each of them should >>>> contain. >>>> >>> >>> Ok, so in this case, let's say we brake it into 3 packages: >>> >>> * scenic (contains the Python app, the documentation, the glade data, >>> and the icon, etc.) >>> * scenic-utils (dc-ctl, firereset, jack-info and milhouse >>> executables. Man pages and some shared libraries) >>> * midistream (python app and man page) >>> > > Maybe it would be nice to also create the scenic-doc package, to > separate the doc from the Python code. (though both are architecture: > all) >
I put the current contents of the package, and how it could split up: https://svn.sat.qc.ca/trac/scenic/wiki/PackagesContents > For now, the docbook documentation (viewable with yelp) are in an > unusual location. (/usr/share/scenic/docbook) It should probably go to > /usr/share/gnome/help/scenic/C/scenic.xml like all gnome docs. Our > docbook doc is made of several XML files and images, though, and we > have two manuals... > >>> The easiest way would be to create 3 *.install files. The quick >>> benefit to this, is that we will have a few packages that are >>> architecture-independant, namely the two Python-only binary packages: >>> scenic and midistream. That totally makes sense. >> >> Yes, that seems sensible (from reading it alone - I must admit that I have >> not yet tried compiling the project and looking at the results). >> > > It's rather complex to actually use it to its fullest - it needs two > computers - but the 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 >> pkg-multimedia-maintainers@lists.alioth.debian.org >> http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers >> >> > > > > -- > 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
