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